FF-Router inklusive Thermometer

Habe heute mal ein wenig gebastelt, und zwar ein kleiner mobiler FF-Hotspot mit der Fähigkeit ueber UMTS Internet zu beziehen und … tada… die Temperatur eines Sensores auszulesen

Das Setup ist ein GL-INET 6416a und als Sensor dient ein DS18b20
http://www.aliexpress.com/item/1Pcs-New-DC5V-DS18B20-Digital-Temperature-Sensor-Module-for-Arduino-Hot-Sale/2054488934.html der Sensor
und der Router toh:gl-inet:gl-inet [Old OpenWrt Wiki]

musste für 3g kompatibilät und gpio eine eigene Firmware bauen und habe die nötigen Pakete in der site.mk nachgetragen

Channels - ThingSpeak IoT resultat ist das…
http://[2a03:2260:50:4:e695:6eff:fe40:2c93]/ds18b20/temp.html

jemand ne Idee wie ich das in der Status page reinfrickeln kann? ( http://[2a03:2260:50:4:e695:6eff:fe40:2c93] )
Ist es evtl auch möglich ueber alfred eigene sensoren oder aehnliches abzugreifen?

Bei bedarf stell ich gern ein howto und Bilder von dem Setup ein

2 „Gefällt mir“

Vote for HowTo vor allem die UMTS Unterstützung interessiert mich brennend

3 „Gefällt mir“

Bezüglich UMTS Support habe ich mich an folgendes Tutorial gehalten: Freifunk:Mobiler Hotspot – Hacksaar Wiki nur dass ich diese Module nicht direkt installieren konnte weil die Kernel Version nicht passend war, daher musste ich sie in der site.mk eintragen bei den benötitigen Pakete und habe eine eigene Firmware dann kompiliert… Sollte machbar sein, würde mir allerdings für die Zukunft wünschen dass Geräte die USB Support haben standardmässig solche Pakete mitliefern in der GLUON Firmware

Sehe ich es richtig, dass es sich um einen I2s-Sensor handelt?
Welche Packages muss ich denn site.mk mit aufnehmen, damit der Kernel mit GPIO-I2C kompliliert und welches Paket zieht die Infos dann zum Alfred hinüber?

(Nein, UMTS interessiert mich nicht, das läuft unter OpenWRT eh nicht reproduzierbar stabil, gibt afaik kein brauchbares Package dafür. Upstream-Problem.)

1-Wire ausgang.
die benötigten Pakete sind

kmod-w1 kmod-w1-master-gpio kmod-w1-gpio-custom

bezüglich alfred habe ich leider kein plan da ich diese info noch selbst suche inklusive integration in der status-page

1 „Gefällt mir“

ich habe hier immernoch meinen 841er an einer 0,5qm-Solarzelle mit Laderegler und 140Wh-Akku.
Nur leider ist mir völlig unklar, wie „knapp“ das denn nachts wird…
Eine Spannungsüberwachung für die Zelle wäre wirklich toll.

wie liest Du denn derzeit die Werte aus?

1 „Gefällt mir“

Die Werte können dann einfach über ein Skript ausgelesen werden der Sensor meldet sich unter /sys/bus/w1/devices/*/w1_slave
ausgabe sieht wie folgt aus:

    root@FF-RE-DS18B20-Mesh:~# cat /sys/bus/w1/devices/28-0000068c9e10/w1_slave
7b 01 4b 46 7f ff 05 10 1d : crc=1d YES
7b 01 4b 46 7f ff 05 10 1d t=23687

Das dazugehörige Bash Script zum auslesen der Daten so:

    #!/bin/bash
catresult=`cat  /sys/bus/w1/devices/28-0000068c9e10//w1_slave | tail -n 1| egrep -o ".{5}$"`
temperature=`echo "scale=2; $catresult / 1000" | bc`
echo $temperature
echo "$temperature" > /lib/gluon/status-page/www/ds18b20/temp.html
# thingspeak api key for channel that data will be logged to
api_key='bla'

# post the data to thingspeak
curl -k --data \
"api_key=$api_key&field1=$temperature" http://api.thingspeak.com/update

Habe bereits recheriert bezüglich Laderegler und ähnliches und 1w aber nichts brauchbares entdeckt… Vielleicht kann man da ja etwas zusammen basteln wo manein Messgerät dranhängen kann und die Spannung des Akkus auslesen kann.

ich sehe leider für ADC „in bezahlbar“ nur HX711 und ADS1115-Module, die allesamt auf I2C laufen.
Was aber auch kein Problem darstellen sollte.
http://www.ebay.de/itm/ADS1115-Module-4-channel-16-Bit-I2C-ADC-with-Pro-Gain-Amplifier-for-Arduino-RPi-/141694533244
Manuell etwas in den Alfred zu holen ist vergleichsweise einfach, da das collector-script eh nur aus /proc&co ausliest. Nur wie man daraus dann gluon-packes baut: Keine Ahnung.

@adorfer

Etwas OT aber das HP-90EPC kann für keines Geld USB Monitoring am Pi.

Der Amazon-Link funktioniert wohl nur mit Deinem (?) Account.

Gefixt.20202020202020

Was spricht denn dagegen, einen AVR mit ADC als 1wire-Slave zu verwenden?

//EDIT: Oder noch einfacher, einen DS2450.

Dafür habe ich noch keine „fertige Platine“ bei ebay und Co gefunden.

SOIC8 Breakout-Boards gibt’s wie Sand am Meer.

die Messwerte können auch auf dem Freifunk-Gerät selbst ausgewertet werden (zb via collectd).
Siehe Statistik von 2009 mit openwrt white russian auf einem Linksys:

Per Alfred lassen sich einzelne Werte auch recht einfach im Mesh verteilen. Mit Werten von Solarladereglern haben wir das beim Solarfestival 2014 realisiert und das läuft seitdem. Man kann hier auch beliebig viele weitere Stationen ins Mesh hängen und deren Messwerte werden sofort integriert.

Einspeisen von Werten (solarfred): https://pad.freifunk.net/public/solartracer
Auslesen von Werten: solarfestival-packages/rpcd-mod-alfred at master · freifunk-leipzig/solarfestival-packages · GitHub

Solarfestival Infovideo siehe Solarfestival 2014 - Freifunk meets Solar Charge Controllers - YouTube
Statistikauswertung via openwrt und collectd siehe http://tracertools.solarfestival.de

Diesen Ansatz haben wir ja schon ein paar Mal diskutiert.
Ich sehe es nur halt nicht ein, an einen Router für unter 20Euro einen Ladekontroller für >50€ (eher >100€) hängen soll. Da stimmt für mich die gefühlte Relation nicht. Daher wäre ich eher ein Freund von GPIO auf 1wire oder I2C und dann den billigst möglichen ADC, der nur simpel die Akku-Klemmspannung liest. Gern auch mit Offset plus nicht-linearer Kurve. Kann man ja eine Mapping-Tabelle bauen und in Software korrigieren.

(WR841N ist halt ein Energiespar-Wunder, da hift es auch nicht dass andere Modelle mehr RAM oder USB haben, die verlangen schlicht nach mehr Elektrizität).

Ich habe mich auch mal ein wenig mit dem Thema Temperatursensor beschäftigt, bin allerdings nicht bei 1-Wire, sondern bei i2c gelandet. Hatte hier noch einen SHT21 von Sensirion rumliegen.

Zunächst habe ich geschaut, wo ich noch 2 freie GPIOs finde. Einer ist ziemlich gut zugänglich (PIN 3 vom JTAG-Header), den anderen musste ich erst suchen. Das ist ein PIN des FLASH. (siehe Bild)

Hardwaremäßig musste ich noch die Pulldown-Widerstände R26 (zwischen JTAG-Header und UART-Header) und R28 auslöten, da I2C ein Idle-High Bus ist. Dafür haben beide Pins einen 10k Pullup Widerstand bekommen.

Hab dann ein paar Pakete nachinstalliert:

opkg update
opkg install kmod-i2c-core kmod-i2c-gpio kmod-i2c-gpio-custom i2c-tools

Mit

insmod i2c-gpio-custom bus0=0,8,9
insmod i2c-dev

wird ein i2c-device erzeugt, welches man mit den i2c-tools benutzen kann.

$>i2cdetect 0 
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

zeigt, an welcher Adresse sich ein Gerät befindet. Mein SHT21 lauscht auf Adresse 0x40, daher ist diese hier aufgeführt.
Dann habe ich noch ein kleines Script gefunden, welches die Werte ausliest und in Temperatur und Luftfeuchtigkeit umrechnet.

#!/bin/sh
RAWTEMP=$(i2cget -y 0 0x40 0xe3 w)
RAWHUMI=$(i2cget -y 0 0x40 0xe5 w)
echo "<html><body>"
if (echo "$RAWTEMP"| grep -Eq '0x[0-9a-f]{4}'); then
   HEXORDERED=$(echo "$RAWTEMP"|sed -r 's/0x([0-9a-f]{2})([0-9a-f]{2})/0x\2\1/')
   DECRAW=$(($HEXORDERED))
   echo $DECRAW | awk -v tem=${DECRAW} '{ printf "%.2f C\n<br>", -46.85+((tem*175.72)/65536)}'
fi
if (echo "$RAWHUMI"| grep -Eq '0x[0-9a-f]{4}'); then
   HEXORDERED=$(echo "$RAWHUMI"|sed -r 's/0x([0-9a-f]{2})([0-9a-f]{2})/0x\2\1/')
   DECRAW=$(($HEXORDERED))
   echo $DECRAW | awk -v hum=${DECRAW} '{ printf "%.2f %%RH\n", -6+((hum*125)/65536)}'
fi
echo "</html></body>"

Ein wenig modifiziert, damit es HTML-Code ausgibt wird dieses Script nun jede Minute durch einen Cron-Job aufgerufen und schreibt seinen Output in /lib/gluon/status-page/www (Cron liegt in /lib/gluon/cron).
Schöner wäre, wenn die Temperatur vom Sensor beim aufrufen der Seite ausgelesen würde, aber das hab ich auf die Schnelle nicht hinbekommen.

Vielleicht hilft das ja jemandem weiter.

5 „Gefällt mir“

So, kleines Update dazu.
Nachdem hier in Dortmund das Autoupdate zugeschlagen hat und die Scripte (dank neuer Gluon-Version) nicht mehr funktionieren, habe ich ein wenig gebastelt und eine bessere Lösung gebaut.

Zunächst benötigt man wie oben angegeben die Pakete. Diesmal die folgenden:

opkg update
opkg install kmod-i2c-core kmod-i2c-gpio kmod-i2c-gpio-custom kmod-hwmon-sht21

Die werden wie oben angegeben mit

insmod i2c-gpio-custom bus0=0,8,9
echo sht21 0x40 > /sys/class/i2c-dev/i2c-0/device/new_device 

geladen. Ich habe die beiden Zeilen in die /etc/rc.local geschrieben, damit die immer beim Start des Routers geladen werden.
Nach dem zweiten Kommando gibt es einen neuen Ordner: /sys/devices/platform/i2c-gpio.0/i2c-0/0-0040/hwmon/hwmon0
In diesem gibt es die beiden dateien „temp1_input“ und „humidity1_input“, in welchen die Temperatur in °C / 1000 und die relative Feuchte in %RH/1000 stehen. Also keine Umrechnerei mehr.

Dann habe ich mich mit LUA rumgeschlagen, um ein script zu bauen, welches eine Website erstellt, wo die beiden Werte drauf stehen.

#!/usr/bin/lua
 
local function main()
  print("Content-Type: text/html")  
print("")      
print("<!DOCTYPE html>")          
io.input('/sys/devices/platform/i2c-gpio.0/i2c-0/0-0040/hwmon/hwmon0/temp1_input')
temp = io.read()
print("<html><body>")
print(temp/1000 .. "C<br>")
io.input('/sys/devices/platform/i2c-gpio.0/i2c-0/0-0040/hwmon/hwmon0/humidity1_input')
hum = io.read()
print(hum/1000 .. " %RH<br>")
print("</html></body>")
end                
 
main()

Das Script habe als temp.lua ich in /lib/gluon/status-page/www/cgi-bin/ gelegt und kann es nun mit http://freifunk/cgi-bin/temp.lua aufrufen und sehe dann dort wie gehabt die Angaben.

1 „Gefällt mir“

Ich arbeite aktuell an einem FF-Solar-Router mit Spannungsanzeige und Steuerung über I2C, und habe mich dabei an Infos aus deinem Post gehalten.

Vorweg: Der Widerstand, welchen du im oberen Foto meinst, ist R29, nicht R28!
R29 und R26 müssen weg, R28 aber keinesfalls.

Die Idee, GPIO 8 als „normalen“ GPIO-Pin einzusetzen, ist aber leider eine äußerst schlechte, wie ich auf die harte Tour feststellen durfte. Ich habe mich bereits vorher gewundert, warum da ein „unbenutzter“ GPIO am Flash-Chip angeschlossen ist…

Beim Programmieren des Codes für meinen Mikrocontroller ist mir dann aufgefallen, dass das ganze prima klappt… Meistens :wink:
in etwa 1 von 20 Aufrufen kommen völlig bescheuerte Daten zurück.
Also das Oszi gezückt und mal geschaut: auf dem GPIO 8 sind tatsächlich (wie man sich hätte denken können) alle Zugriffe auf den Flash-Chip zu sehen. Die stören natürlich grob in der I2C Kommunikation und verfälschen jegliche Kommunikation.

Kurz-gesagt: GPIO 8 lieber in Ruhe lassen! Ich habe bereits etwas auf dem Board gesucht und leider keinen weiteren „direkten“ GPIO gefunden, werde mich jetzt also einmal dran machen, die LEDs zu deaktivieren (möchte man bei einem Solarrouter ja eh nicht) und dann als I2C-Bus zu verwenden.

Viele Grüße,
Manawyrm

Das macht schon mal einen sehr guten Eindruck :slight_smile:
Ich habe direkt im Kernel die Registration der GPIOs als LEDs auskommentiert. Dann kann man die normal nutzen.

EDIT: Viel zu kompliziert gedacht :smile:
Man kann den Kram aus dem Userspace abwürgen! :smiley:

echo "leds-gpio" > /sys/bus/platform/drivers/leds-gpio/unbind

Dann lassen sich die LEDs auch als GPIO nutzen.

EDIT2:

Da sind noch 2 GPIOs, welche man durchaus gut erreichen kann :wink:
Ich werde morgen dann mal sicherstellen, dass die nicht doch irgendwas machen, dann werde ich da mal mein I2C draufgeben… So muss man nicht die LEDs sacrificen :smile_cat:

Viele Grüße,
Manawyrm

5 „Gefällt mir“