Go Down

Topic: opkg fails to install luci-app-statistics (Read 5453 times) previous topic - next topic

tdicola

May 07, 2014, 10:59 pm Last Edit: May 07, 2014, 11:02 pm by tdicola Reason: 1
Hey all, I'm running the latest Yun image but am having a problem installing the luci-app-statistics package.  From what I understand this is a package to install a nice graphing interface in the luci web panel, based on stats gathered with collectd and graphed with rrdtool.  Here's a a blog post about setting it up on OpenWRT that I was following--ultimately I want to play around with measuring data from the ATmega and throwing it into an RRD database that is graphed in luci.

However the problem I'm running into is running opkg install luci-app-statistics fails with this error:

Code: [Select]

root@Arduino:~# opkg install luci-app-statistics
Installing luci-app-statistics (0.11+svn10180-1) to root...
Downloading http://downloads.arduino.cc/openwrtyun/1/packages/luci-app-statistics_0.11+svn10180-1_ar71xx.ipk.
Collected errors:
* opkg_download: Failed to download http://downloads.arduino.cc/openwrtyun/1/packages/luci-app-statistics_0.11+svn10180-1_ar71xx.ipk, wget returned 8.
* opkg_install_pkg: Failed to download luci-app-statistics. Perhaps you need to run 'opkg update'?
* opkg_install_cmd: Cannot install package luci-app-statistics.


I have run opkg update, in fact if I run opkg list | grep luci-app-statistics I can actually see the package in the list:
Code: [Select]

luci-app-statistics - 0.11+svn10180-1 - LuCI Statistics Application


Odd that the package is in the list but fails to download and install.  Anyone who is more familiar with the packages and repository have an idea what might be wrong?  Thanks!

federicofissore

Have you tried again? It looks like "dreamhost" (the file hosting service we use) has performed an upgrade in the past days: maybe they are still fixing bugs

sonnyyu

At this moment, luci-app-statistics is still broken.

Code: [Select]
http://downloads.arduino.cc/openwrtyun/1/packages/luci-app-statistics_0.11+svn10180-1_ar71xx.ipk
<Error>
<Code>AccessDenied</Code>
</Error>

federicofissore

It's a problem with a dreamhost, the service we use. We cannot fix it even re-uploading the file. We've opened an enquiry. I'll keep you posted

tdicola

Ah gotcha, thanks for the followup.  I'll take a look at grabbing the ipk from my local build of the yun image.

tdicola

So this is pretty cool, I've installed luci-app-statistics and collectd-mod-exec packages and found a not too difficult way to get realtime graphs of data on the Yun.  The exec plugin runs a specified script or command which sends measurement data to standard out in a special format.  Luci statistics adds a new tab in luci that shows charts for data logged by collectd, including custom data logged by the exec plugin.  The slick thing is that all of this is configured through the luci interface.

The only thing missing out of the box is some lua code to tell luci how to graph the data read by the exec plugin, and a script to grab data from the ATmega and send it to collectd using the exec plugin.  I'm working on something general for both so you could output sensor values to the console in a sketch (with a simple format like "Name:value", i.e. "Light sensor:999") and have it show up in the statistics charts automatically.  Here's a quick look using randomly generated data right now:


Should have it working next week and will post more details.


federicofissore

We just released an update. Please upgrade opkg with
Code: [Select]

opkg update
opkg upgrade opkg


ShapeShifter

#8
Nov 04, 2014, 08:30 pm Last Edit: Nov 04, 2014, 08:30 pm by ShapeShifter
So this is pretty cool
Yes, it is!  8)  I've been playing with collectd a little bit. Displaying it this way is MUCH easier than writing web pages to call rrdcgi.

Collecting memory and disk space is interesting, but I really wanted to be able to collect and display sensor data collected from a sketch. The collectd python plugin sounded like a good solution, but that plugin doesn't appear to be available for the Yun? (At least not through opkg, or at least not that I could find.)

I just found this post where you are using python with the exec plugin. I wanted to avoid exec because it spawns a new process on each sample, at least that's what I heard. But by putting a loop in it, it seems you've found a way around this overhead. Nice.

I handled getting the data from the sketch a little differently than you, I used the Bridge library. The sketch reads a set of temperature sensors, and uses Bridge.put() calls to save the current values. Then the python script periodically uses the Bridge to get() the values and send them to collectd. This is my python script:

Code: [Select]
#!/usr/bin/python

# A python script designed to be run by the exec module of collectd.
# It uses the Bridge library to "get" values that were "put" by the sketch.
# This script assumes that there will be a value 'tempCnt' that indicates
# how many temperature values there are to read. The actual values are
# named 'tempF_1', 'tempF_2', etc.

import os
import sys
import time
sys.path.insert(0, '/usr/lib/python2.7/bridge/')

from bridgeclient import BridgeClient as bridgeclient
bridge = bridgeclient()

# Read hostname environment variable set by collectd exec plugin.
hostname = os.environ.get('COLLECTD_HOSTNAME', 'localhost')

while True:
    #Gather temperatures
    count = int(bridge.get('tempCnt'))
    if count > 0:
        for c in range(count):
            # Form the name and get the value from the bridge
            key = 'tempF_{0}'.format(c+1)
            temp = bridge.get(key)

            # Make sure a value was actually read
            if (temp != None):
                #output value to be sent to collectd exec plugin
                print 'PUTVAL "{0}/exec-{1}/gauge" {2}:{3}'.format(hostname, key, 0, temp)

    sys.stdout.flush()

    # give up processing time to not bog down the CPU and limit the update rate
    time.sleep(10)



Just another way of approaching it. It may be a little more overhead using the Bridge, but it doesn't require parsing data on the python end. And, for my application, I also wanted to be able to remotely retrieve the current data values without having to tap into the collectd stream: using the bridge gives you the ability to access "http:arduino.local/data/get" to retrieve all bridge data values -- for free with no extra code needed!

Angelo9999

I handled getting the data from the sketch a little differently than you, I used the Bridge library. The sketch reads a set of temperature sensors, and uses Bridge.put() calls to save the current values. Then the python script periodically uses the Bridge to get() the values and send them to collectd. This is my python script:

Code: [Select]
#!/usr/bin/python

# A python script designed to be run by the exec module of collectd.
# It uses the Bridge library to "get" values that were "put" by the sketch.
# This script assumes that there will be a value 'tempCnt' that indicates
# how many temperature values there are to read. The actual values are
# named 'tempF_1', 'tempF_2', etc.

import os
import sys
import time
sys.path.insert(0, '/usr/lib/python2.7/bridge/')

from bridgeclient import BridgeClient as bridgeclient
bridge = bridgeclient()

# Read hostname environment variable set by collectd exec plugin.
hostname = os.environ.get('COLLECTD_HOSTNAME', 'localhost')

while True:
    #Gather temperatures
    count = int(bridge.get('tempCnt'))
    if count > 0:
        for c in range(count):
            # Form the name and get the value from the bridge
            key = 'tempF_{0}'.format(c+1)
            temp = bridge.get(key)

            # Make sure a value was actually read
            if (temp != None):
                #output value to be sent to collectd exec plugin
                print 'PUTVAL "{0}/exec-{1}/gauge" {2}:{3}'.format(hostname, key, 0, temp)

    sys.stdout.flush()

    # give up processing time to not bog down the CPU and limit the update rate
    time.sleep(10)



Just another way of approaching it. It may be a little more overhead using the Bridge, but it doesn't require parsing data on the python end. And, for my application, I also wanted to be able to remotely retrieve the current data values without having to tap into the collectd stream: using the bridge gives you the ability to access "http:arduino.local/data/get" to retrieve all bridge data values -- for free with no extra code needed!
That's very useful, thanks!
https://github.com/sngl

Go Up