Jump to content


  • Posts

  • Joined

Posts posted by tkaiser

  1. Testing it, looks great, if it could be expanded with more monitoring featires - would be great!


    RPi-Monitor can be extended nearly unlimited since version 1.2 or 1.3 regarding custom data sources and various output types and starting with 2.10 also to customize the web pages extensively and include every stuff you like.


    The focus of my additions was simply to address the different data sources on sunxi devices regarding thermal things and power consumption (and some sort of a daemon to collect data since in my test setups -- torturing the devices under full load -- RPi-Monitor often failed to collect some stuff due to timeouts: ie querying a disk for its internal temperature under full load --> takes often more than a second to respond and in the meantime RPi-Monitor already gave up).


    If you want add the stuff you mentioned you can start directly. Just become familiar with RRD data collection types (GAUGE vs. COUNTER vs. DERIVE and so on) and how you apply regex to filter raw data and you're done. There are plenty of examples available on the web and you get many ideas by reading the full post including comments/links here: http://rpi-experiences.blogspot.fr/2013/06/rpi-monitor-version-20-advance-usage.html


    But since it sounds you like to monitor a router I would suggest checking better options first (eg. fully blown monitoring solutions that know alerts and triggers like OpenNMS or OMD -- prebuilt for ARMv7)

  2. I believe I don't get your setup. Is there an external DHCP server behind the WAN interface or should the R1 play both NAT router, DHCP server (and of course caching DNS server)?


    If it's the latter I would do a web search for "dnsmasq nat howto": basically dnsmasq will serve dhcp/dns purposes and the NAT stuff will be handled by uncommenting 'net.ipv4.ip_forward=1' in /etc/sysctl.conf amd the iptables stuff taken from Tido's manual. But maybe the whole thing is already covered by Tido in his manual...

  3. When you divide by 100 do not use "$1/100" but "sprintf("%.1f", $1/100)" instead as regex. As a reference my whole config that deals with A20/AXP209, several sensor sources and now also CPU stats: http://pastebin.com/ARcjtjzL


    I do not read out the sensors directly but let my temperature daemon preprocess the raw data (sanitizes numbers if sensors report anomal values as it happens sometimes and does some averaging to get smoother graphs):









    For CPU stats I use a function that will be called every 20 seconds and processes the counters present in /proc/stat and writes the 6 values I'm interested in (see last graph above) into /tmp/cpustat from where they were picked up by a RPI-Monitor regex:

    ProcessStats() {
    	set $(awk -F" " '/^cpu / {print $2"\t"$3"\t"$4"\t"$5"\t"$6"\t"$7"\t"$8}' </proc/stat)
    	UserDiff=$(( ${UserStat} - ${LastUserStat} ))
    	NiceDiff=$(( ${NiceStat} - ${LastNiceStat} ))
    	SystemDiff=$(( ${SystemStat} - ${LastSystemStat} ))
    	IdleDiff=$(( ${IdleStat} - ${LastIdleStat} ))
    	IOWaitDiff=$(( ${IOWaitStat} - ${LastIOWaitStat} ))
    	IrqDiff=$(( ${IrqStat} - ${LastIrqStat} ))
    	SoftIrqDiff=$(( ${SoftIrqStat} - ${LastSoftIrqStat} ))
    	Total=$(( ${UserDiff} + ${NiceDiff} + ${SystemDiff} + ${IdleDiff} + ${IOWaitDiff} + ${IrqDiff} + ${SoftIrqDiff} ))
    	CPULoad=$(( ( ${Total} - ${IdleDiff} ) * 100 / ${Total} ))
    	UserLoad=$(( ${UserDiff} *100 / ${Total} ))
    	SystemLoad=$(( ${SystemDiff} *100 / ${Total} ))
    	NiceLoad=$(( ${NiceDiff} *100 / ${Total} ))
    	IOWaitLoad=$(( ${IOWaitDiff} *100 / ${Total} ))
    	IrqCombinedLoad=$(( ( ${IrqDiff} + ${SoftIrqDiff} ) *100 / ${Total} ))
    	echo "${CPULoad} ${SystemLoad} ${UserLoad} ${NiceLoad} ${IOWaitLoad} ${IrqCombinedLoad}" >/tmp/cpustat
    } # ProcessStats
  4. Just a small follow-up: To get an idea what's going on inside enclosures I added one DS1820 externally to get ambient temperature and one DHT11 inside the server's enclosure close to the PSU (took me some time to patch the programm to read out the DHT11 without a pull-up resistor and to realize that it's not enough to add w1-gpio and w1_therm to /etc/modules when w1_sunxi is missing to be able to talk to the DS1820).


    Since the device is some sort of a surveillance server (feeds 5 RPi B+ with camera module via PoE and both records their video streams and 'transcodes' to be accessible in realtime via VLC) I also added the ability to record the internal temperature of all 5 PiSpy cams:





    RPi-Monitor is really great to realize obvious relationships otherwise invisible :-)

  5. I also think hddtemp is either missing or needs a fix (when the disk model is too young). You should give the following a try

    hddtemp /dev/sda --debug

    In case you've an USB disk check the comments regarding smartctl/hdparm (and be aware that when you're running wheezy that you might need to patch a smartmontools script since the version shipping with Wheezy is outdated as hell)





    BTW: I reworked the sunxi_tp_temp code to be able to deal with both A10 and A20 (they've different temperature curves and I tried to adopt the new code from kernel 4.x for this). And with Yuri's help we're now able to distinguish between A10 and A20 (and possibly A13 as well. The A13 is said to have the same thermal sensor as A20 but is otherwise A10's direct sibling):

    CheckSunxiHardware() {
            SunxiGeneration="$(awk -F" " </proc/cpuinfo '/^Hardware/ {print $3$4}')"
            case ${SunxiGeneration} in
                            # A20
                            CpuPart="$(awk -F" " </proc/cpuinfo '/^CPU part/ {print $4}')"
                            case ${CpuPart} in
                                            echo "A20: /path/to/sunxi_axp209_temp 144700 100"
                            CpuRevision="$(awk -F" " </proc/cpuinfo '/^Revision/ {print $3}')"
                            case ${CpuRevision} in
                                            # A13
                                            echo "A13: /path/to/sunxi_axp209_temp 144700 100"
                                            # A10
                                            echo "A10: /path/to/sunxi_axp209_temp 257000 133"
    } # CheckSunxiHardware

    Will ship this as an update soon.

  6. Any further hint for me?


    It seems on your system no unprivileged user exists and therefore the rpimonitor's web process doesn't start. I would try to create a user tim (with which you should connect from then on -- working as root isn't the best idea):

    ​/usr/sbin/useradd -d /home/tim -m -s /bin/bash tim
    gpasswd -a tim sudo
    passwd tim
    service rpimonitor start

    You should be able to login from then on as 'tim' and become root via 'sudo su -'

  7. FYI: Testing finished / feature freeze. I submitted a second pull request to Xavier to include the current state with the next RPi-Monitor release.


    In case you've further comments feel free to discuss them here :-)


    If you want to try it out in the meantime you should follow these steps:

    # become root eg. by "sudo su -"
    cd /tmp && wget http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz
    md5sum sunxi-monitor.tar.gz | grep -i 6822bcd7fe5cb2403eed9747e7cfff52 || exit 1
    service rpimonitor stop
    cd / && tar -xzf /tmp/sunxi-monitor.tar.gz
    pkill -f '/bin/bash /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh' 2>/dev/null
    nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &
    service rpimonitor start

    If you chose the first installation method (compare with http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html please) then when RPi-Monitor 2.11 will be released all you've to do is a simple 'apt-get update/upgrade' and you're done. You should keep in mind that when you change templates then create them with a new and unique name otherwise conflicts while doing 'apt-get upgrade' will occur.

  8. FYI: Running the very same test (" cd /mnt/sda/ && stress -t 900 -c 2 -m 2 -i 2 -d 2"), first time with the R1 being powered through the LiPo connector and second run through the crappy Micro-USB power-in (consumption peaks and voltage drops down to 4.7V -- the PSU provides 5.0V and with just 20 cm cable and Micro-USB we loose between 0.1-0.3V idle/load)

    Powered through battery connector:
    Powered the crappy way through Micro-USB connector:

    I did simply stop rpimonitor, copied files downloaded from you and rpimonitor start. If you need some additional info, let me know.


    Ah, ok. I forgot to mention that it's essential to stop and restart the temperature daemon since the old daemon writes 'degrees * 1000' into the temp files and the new one only 'degrees * 10'. So currently you have a mismatch between the daemon reporting old values and the config interpreting according to new rules.

    pkill -f '/bin/bash /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh' && (cd /tmp && nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & )

    should do the job (or a reboot if you want to play Windows  :P )

  10. Check Status/Temperature ;) Decimal separator missing ;)

    This is very nice tool to understand, how the board working. And what about the BCM chip in R1? There is no monitoring feature?


    Can you please elaborate on the error you get? A screenshot or terminal output (if it's directly related to the temp daemon) would help.


    Regarding the switch IC: I don't know whether it has a thermal sensor inside that can be queried. I would doubt it. For network packets you have to query kernel interfaces. But I don't know whether the BCM provides per port statistics.

  11. Glad you resolved it. But you should be prepared that other stuff might break now (I believe this is defined for a reason). $TERM is an ugly beast ;-)


    An alternative approach is to use aliases (since it seems to only affect one single tool you use).

    alias mc="TERM=xterm /usr/bin/mc"

    in one of the startup files read by bash and you're done (and don't introduce yet unknown side effects). Also useful if you've other terminal related problems or you just dislike colors in some programs:

    alias mcm="TERM=xterm-mono /usr/bin/mc"

    Now "mcm" would invoke a b/w mc instance. Aliases are powerful. Since I'm a lazy guy I even use them to open stuff from the command line in Cocoa apps (on OS X -- of course  :P )

    macbookpro-tk:~ tk$ type photoshop
    photoshop is aliased to `open -a /Applications/Adobe\ Photoshop\ CC\ 2015/Adobe\ Photoshop\ CC\ 2015.app'
  12. It looks, that hddtemp.rrd is missing in  /var/lib/rpimonitor/stat/ after installation?? When I created the one, everything works well.


    Thx for reporting that, found the problem. It was defined as "GAUGE " with trailing whitespace instead of "GAUGE".  :wacko:


    I fixed that (as well as other stuff, eg. smoothing temperature graphs for SoC/PMU, less frequent disk checks, configurable check interval and so on):


    http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz (MD5: 6822bcd7fe5cb2403eed9747e7cfff52)


    Same procedure as before. Stop rpimonitor, untar from / and restart. Now everything should work out of the box. Feedback welcome!

  13. echo $TERM gives "linux".

    With "TERM=xterm mc" the F-keys behave correct.


    How to set this persistant?


    I don't know where the defaults are stored. So it depends on the shell you use. If you're using zsh you would add "export TERM=xterm" to ~/.zshrc and if you're using bash instead you would have to write it to both ~/.bashrc and ~/.bash_profile (see chapter INVOCATION in bash's manual page -- for whatever reason one file is read when you start a login shell and the other if it's a not a login shell)

  14. I am working on Ubuntu 14.04 with it's defaults.


    Hmm... I thought installing Linaro's standalone cross-compiler toolchain is recommended? I use




    and unpacked it in /usr/local and define 

    export PATH="/usr/local/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/bin/:$PATH"

    @Yuri: Since you're using an A10 I would love to get feedback regarding reading out thermal values from its TP's thermal sensor inside. Please have a look at this thread. Would be great if you could unpack the sunxi-monitor.tar.gz archive and provide the output of

    /usr/share/rpimonitor/scripts/sunxi_tp_temp 1447

    to get a clue whether this approachs works on A10/A13 as well. Thx (and sorry for thread hijacking)

  15. But i cannot enter the Website by enter http://bananaIP:8888


    Since you get "This Site is not available" and RPi-Monitor has its own web server you might check which process is listening on port 8888 and in case there is the other web app then adjust /etc/rpimonitor/daemon.conf (add a line with eg. "daemon.port=8088" and try to access this port afterwards) and restart rpimonitor afterwards. To check which process listens of which port you could use 

    lsof -i

    BTW: Your ps output only shows the rpimonitord process responsible for collecting data (and running as root). The web server runs under an unprivileged account (and it seems in your case it does not run maybe due to port conflicts)

  16. how can I examine, what was happens?


    I you don't find any informations in the logs (var/log/syslog) then you should have a closer look whether it's really off (eg. caused by an emergency shutdown due to overheating or undervoltage) or you aren't able to interact with the Board.


    In general it's a good idea to use monitoring to get a clue what's going on. In case you're using Kernel 3.4 then RPi-Monitor would be the weapon of choice (see pinned thread in this forum)

  17. Hi,


    I started to adjust RPi-Monitor's settings for the Banana Pi a while ago and reworked the whole stuff in the meantime (since it was focused on Banana Pi and some parts were too quick&dirty -- especially temp file handling of the temperature daemon). I also adjusted the consumption measurements for Lamobo R1 since it's the best idea to power the board through the LiPo battery connector -- for this case you need the axp209_cpu_pmu_temp_r1.conf template!


    Here you find an installation overview for RPi-Monitor (takes you 3 minutes if you are able to copy&paste): http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html


    Here you find what's different on sunxi: https://github.com/ThomasKaiser/RPi-Monitor/blob/master/README_sunxi.md


    Here you find the adjustments: http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz (MD5: 6822bcd7fe5cb2403eed9747e7cfff52. It will take you additional 3 minutes to 'install' -- see below)


    The archive contains the following:


    Contents: data.conf is relinked to template/sunxi_axp209.conf which includes all the basic RPi-Monitor stuff but uses template/axp209_cpu_pmu_temp.conf for all the A10/A20/AXP209 specific stuff since this differs totally from Raspberry Pi. The sunxi_tp_temp binary is able to read out A20's temperature and sunxi-temp-daemon.sh is a script I rewrote from scratch since it's not possible to collect thermal data from disks/SoC under heavy load (RPi-Monitor isn't that patient waiting for external ressources to respond. So I created a daemon that collects thermal data into 3 temporary files and redirect RPi-Monitor to read from there).


    WARNING: Most of the sunxi stuff works only with kernel 3.4.x since in mainline the I2C/sysfs interface to the AXP209 PMU disappeared.


    Installation: Install RPi-Monitor as outlined in the link above, then stop it, untar the archive from /, ensure that /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh will be running and start rpimonitor again.

    # become root eg. by "sudo su -"
    service rpimonitor stop
    cd / && tar -xzf /path/to/sunxi-monitor.tar.gz
    nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &
    service rpimonitor start

    To let the collection of thermal data survive a reboot it's a good idea to add "/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &" prior to "exit 0" to /etc/rc.local









  18. Sure. In the mean time I am preparing deb repository so if everything went ok, next build will be apt-get update-able.


    That sounds great. BTW: Testing with 4.2-rc3 I always ended up relinking /boot/zImage manually (no idea why).


    BTW: The sunxi-mmc patch seems to work so I would propose an immediate inclusion: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested?start=30#3038

  19. i'm getting the following error, when i try to login me as root:

    Authentication token manipulation error


    You might also run into this error if for whatever reasons the rootfs is set read-only: I made this experience myself when fiddling around with other FS for the rootfs: http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/?p=573


    In case you're always using the same SD card I would first test whether it's physically ok. Use either H2testw or F3 on Linux or OS X.

  • Create New...