Gewichtsmessung via Bluetooth mittels Wii Fit Board - Hilfe/ Diskussion

[tomster]

Servus zusammen!

Ich hab mir seit einigen Tagen ein paar Gedanken gemacht, wie man eine Gewichtsmessung in FHEM integrieren könnte. Hintergrund ist, dass ein guter Freund in ein paar Tagen eine Kneipe aufmacht und ich mir überlegt habe, für was man den ohnehin schon dort installierten FHEM-Server sonst noch verwenden könnte. Klar! Zum Feststellen des Füllstandes der Bierfässer (Temperatur sowieso). Die Theorie lautet:
Gewicht Fass - (Leergewicht + Zapfzeug) = Liter im Faß...

Meine originäre Idee eine BT-Billigwaage (15$ mit Versand) aus dem fernen Osten zu verwenden, scheiterte an mangelnder Kommunikationsbereitschaft der Hersteller. Bei reiferer Überlegung zufälligem Blick unter den Wohnzimmerschrank ist mir dann das Wii Fit Board meiner Kinder untergekommen. Das hat BT, verträgt Gewichte bis ~150kg und ist in der Bucht für verhältnismäßig geringes Geld zu schiessen. Der Spezl hat ja schließlich ein paar Fässer an der Zapfanlage.
Nach einer kurzen Googelei heute Nachmittag bin ich dann auf diese Seite gestossen:
https://github.com/InitialState/beerfridge/wiki

Ha! Das ist doch eigentlich genau was ich suche. Das zu Grunde liegende Script ist zwar in Python (von dem ich keine Ahnung habe), aber ich denke, die Ausgabe des Scripts ließe sich auch von FHEM in Perl (von dem ich ebenfalls keine Ahnung habe) auswerten. Und genau an dieser Stelle wäre vermutlich der richtige Zeitpunkt zu fragen, ob jemand von Euch hierzu eine Idee hat, bzw. mir Hilfestellung geben könnte? Man kann ja theoretisch sogar eine Körperwaage damit realisieren, falls dieses Argument mehr Zuspruch bei jemandem von Euch findet

Eine Frage wäre wohl sicherlich, ob das Script mit mehreren Fit Boards gleichzeitig kommunizieren kann oder ob z.B. bei multiplen Instanzen Probleme mit dem Zugriff auf den BT-stack entstehen. Ich möchte ehrlich gesagt nur ungern je einen Pi pro Fass verwenden müssen.

Alternativ könnte auch XWiimote weiterhelfen: https://github.com/dvdhrm/xwiimote

Was haltet ihr von der Idee?

[Ralf W.]

http://forum.fhem.de/index.php?topic=39120.0

MfG

[tomster]

Danke! Dann werd ich Mal den Rince kontakten...

[Rince]

Hiho
Hast mich erwischt

Was ich im Moment sagen kann, ist dass der Python Code von dem optischen Sensor (siehe Wiki) Daten an fhem sendet. Das funktioniert soweit sehr gut.
Prinzipiell kannst du die CodeTeile aus dem Skript im Wiki einfach per Copy&Paste übernehmen, um die Ausgaben nicht auf der Console zu haben, sondern eben an fhem zu senden.

Das dürfte ausgesprochen wenig Anpassung nötig machen.

Das war der generische Teil der Antwort.

Jetzt der andere:
Ich finde die Idee nicht unspannend. Was mir abgeht, ist eine Art Verwendungszweck
Ich habe so eine lustige Withings Edelwaage, brauche also keine Wii Fit Board

Gewicht Fass - (Leergewicht + Zapfzeug) = Liter im Faß...

Ist vermutlich nicht richtig. Jedenfalls dann nicht, wenn das Fass an einer Zapfanlage hängt.

Eine Frage wäre wohl sicherlich, ob das Script mit mehreren Fit Boards gleichzeitig kommunizieren kann

Sicherlich kann es das nicht. Notwendig ist das aber auch nicht zwangsläufig, da jede Wii Fit ja einen anderen Code verwendet. Ergo würde man wohl den Code als Parameter an das Programm übergeben, und so die Waagen halt der Reihe nach abfragen. Die Abfrage rauswerfen, und statt dessen mit der Adresse aus dem Config-File arbeiten.

Sind wir ehrlich:
Man braucht keine 100 Messungen / Sekunde. 1 / Minute dürfte mehr als ausreichend sein. Bei Unter 10 Litern im Fass würde ich eine gelbe Lampe anwerfen, dass demnächst wer ein neues Fass rankarren soll (Ich kenn ja die Kneipe nicht; Wenn es Pils ist, welches 8 Minuten zum einschenken braucht, sind 10 Liter vermutlich eh nicht so schnell ausgeschenkt, ist es in einem bayerischen Bierzelt dürften 10 Liter in deutlich kürzerer Zeit verschwinden )


Was mich bis dato an den beiden Ansätzen stört:
Das Pairing mit dem Knopf an der Wii Fit ist einfach unpraktikabel. Wobei ich nicht weiß, ob bei der vorgeschlagene API dies ebenso zu einem Problem wird, wird auf dem von mir verlinktem Skript (das auch für das Instructable die Grundlage darstellt.

Lösungsansatz Pairing:
An den Taster in der Wii Fit ein potentialfreies Relais löten, selbiges an einen freien GPIO, und dem Skript beibringen, den Taster sozusagen kurz zu brücken. Meinetwegen auch über fhem selber.
Skript kommt an den Punkt wo Taster gedrückt werden muss, informiert fhem, fhem "drückt Taster" Skript läuft weiter, rmittelt Gewicht, teilt dies fhem mit und beendet sich.

Skript wird im Minutentakt von fhem aufgerufen

[tomster]

Was ich im Moment sagen kann, ist dass der Python Code von dem optischen Sensor (siehe Wiki) Daten an fhem sendet. Das funktioniert soweit sehr gut.
Prinzipiell kannst du die CodeTeile aus dem Skript im Wiki einfach per Copy&Paste übernehmen, um die Ausgaben nicht auf der Console zu haben, sondern eben an fhem zu senden.

Das dürfte ausgesprochen wenig Anpassung nötig machen.

Das war der generische Teil der Antwort.

Jetzt der andere:
Ich finde die Idee nicht unspannend. Was mir abgeht, ist eine Art Verwendungszweck
Ich habe so eine lustige Withings Edelwaage, brauche also keine Wii Fit Board

Du schriebst im anderen Thread, dass Du script-seitig einen entsprechenden Code bereits erstellt hast. Magst Du mir den zukommen lassen? Anwendungszweck hätt ja ich, wenn Dir kein gscheiter einfällt Und diese Withings-Nummer ist mir für meinen Fall schlichtweg zu teuer.

Ist vermutlich nicht richtig. Jedenfalls dann nicht, wenn das Fass an einer Zapfanlage hängt.

Klar hängt das Fass an einer Zapfanlage, aber mit "Zapfzeug" ist das Gewicht der Keg-Anschlüssee und die Schläuche gemeint. Und die halbe Halbe Bier, die noch in den 2,5 Metern Schläuchen rumlungert kann man getrost vernachlässigen, mein ich.

Sicherlich kann es das nicht. Notwendig ist das aber auch nicht zwangsläufig, da jede Wii Fit ja einen anderen Code verwendet. Ergo würde man wohl den Code als Parameter an das Programm übergeben, und so die Waagen halt der Reihe nach abfragen. Die Abfrage rauswerfen, und statt dessen mit der Adresse aus dem Config-File arbeiten.

Klingt  (generisch) simpel. Praktisch hab ich jedoch keinen Plan wie Du das meinst...

Sind wir ehrlich:
Man braucht keine 100 Messungen / Sekunde. 1 / Minute dürfte mehr als ausreichend sein. Bei Unter 10 Litern im Fass würde ich eine gelbe Lampe anwerfen, dass demnächst wer ein neues Fass rankarren soll (Ich kenn ja die Kneipe nicht; Wenn es Pils ist, welches 8 Minuten zum einschenken braucht, sind 10 Liter vermutlich eh nicht so schnell ausgeschenkt, ist es in einem bayerischen Bierzelt dürften 10 Liter in deutlich kürzerer Zeit verschwinden )

Genauso ist das in etwa geplant. Die schier irrwitzige Anzahl an Messungen ist wohl in mehrerlei Hinsicht blanker Unsinn. Fass-Pils kommt ohnehin nicht in die Wirtschaft! Da täten wir ja allesamt verdurschten bei 8 Min. Wartezeit + Service pro 0,33-Getränk (ohnehin eine unsägliche dämliche Gebindegröße)! Tendenziell würde ich den Bierdurchsatz durchaus eher Wiesn-like veranlagen. Mia Bayern ham halt Durscht

Was mich bis dato an den beiden Ansätzen stört:
Das Pairing mit dem Knopf an der Wii Fit ist einfach unpraktikabel. Wobei ich nicht weiß, ob bei der vorgeschlagene API dies ebenso zu einem Problem wird, wird auf dem von mir verlinktem Skript (das auch für das Instructable die Grundlage darstellt.

Das Pairing sollte doch (zumindest im Stavros'schen Howto) automatisch ablaufen... Oder hab ich da was mißverstanden?
Für das Initialpairing hab ich mir gedacht, ich schraub das Board auf und löte einfach einen Taster an die beiden Kontakte, den ich dann am Board seitlich einbaue. Damit kann die Taste auch in beladenem Zustand gedrückt werden, wenn notwendig.

[Rince]

Du schriebst im anderen Thread, dass Du script-seitig einen entsprechenden Code bereits erstellt hast. Magst Du mir den zukommen lassen?

Das ist der, der in der Wiki steht.

Auszugsweise:

Code Auswählen Erweitern


import urllib
...
# Pixelanzahl an fhem senden
# fhem Kommando erzeugen
url = (conf["fhem_host_port"])
request = (conf["fhem_request"])
command = (conf["fhem_command" + "_" + str(i)])
value =  "%20" + str(white)
fhem = url + request + command + value
#print fhem
urllib.urlopen(fhem)


Die Teile mit (conf[" ... "] sind im Config File definiert, so dass man nicht dauernd am Skript spielen muss, sondern ggfs. einfach mit verschiedenen Config-Files arbeiten kann, um andere Werte zu übermitteln.

Klingt  (generisch) simpel. Praktisch hab ich jedoch keinen Plan wie Du das meinst...

Schau mal bei dem GitHub beerfridge, Part 2 Bluetooth-Setup:

$ hcitool dev
Devices:
    hci0    00:1A:7D:DA:71:13

Das ist offenbar die Bluetooth Adresse eines Wii Fit Boards.


Eine Seite weiter:

Run the wiiboard_test.py script to test communication and take weight readings from the Wii Balance Board:

$ sudo python wiiboard_test.py
You will see the following response:

Discovering board...
Press the red sync button on the board now
Remove the battery cover underneath the Board to locate the red sync button. Make sure you press the button within a few seconds of running the script or a timeout will occur. Once successful, you will see something similar to the following:

Found Wiiboard at address 00:23:CC:2E:E1:44
Trying to connect...
Connected to Wiiboard at address 00:23:CC:2E:E1:44
Wiiboard connected
ACK to data write received
84.9185297 lbs
84.8826412 lbs
84.9275927 lbs

Das ist der Teil, wo man wohl ansetzen muss:
Wir brauchen keine Erkennung des Boards.
Viel mehr legen wir uns für jedes Board eine eigene Config-Datei ab, in die wir die Adresse jeweils reinschreiben.



Jetzt mal bei skorokithakis nachgelesen:

Usage

You can run it with:

./gr8w8upd8m8.py
It will prompt you to put the board in sync mode and it will search for and connect to it.

If you already know the address, you can just specify it:

./gr8w8upd8m8.py <board address>
That will skip the discovery process, and connect directly.

gr8w8upd8m8 uses the bluez-test-device utility of bluez-utils to disconnect the board at the end, which causes the board to shut off. Pairing it with the OS will allow you to use the front button to reconnect to it and run the script.

Calculating the final weight is done by calculating the mode of all the event data, rounded to one decimal digit.

Feel free to use processor.weight to do whatever you want with the calculated weight (I send it to a server for further pointless processing).

Deine Gedanken:

Das Pairing sollte doch (zumindest im Stavros'schen Howto) automatisch ablaufen... Oder hab ich da was mißverstanden?
Für das Initialpairing hab ich mir gedacht, ich schraub das Board auf und löte einfach einen Taster an die beiden Kontakte, den ich dann am Board seitlich einbaue. Damit kann die Taste auch in beladenem Zustand gedrückt werden, wenn notwendig.

Hm. Wenn ich ehrlich bin, ich verstehe es auch nicht
jrbail01 auf GitHub (beerfridge) schreibt, mann muss neu pairen, den entsprechenden Part von skorokithakis (das die Grundlage darstellt) verstehe ich nicht. Jedoch denke ich, dass auch ein Pairing immer noch einen Tastendruck braucht. 

Pairing it with the OS will allow you to use the front button to reconnect to it and run the script.

Für das Initialpairing hab ich mir gedacht, ich schraub das Board auf und löte einfach einen Taster an die beiden Kontakte, den ich dann am Board seitlich einbaue. Damit kann die Taste auch in beladenem Zustand gedrückt werden, wenn notwendig.

Hm
Hmmmm
Hmmmmmmmm

Das ist schlecht.
Wenn das Pairing doch bestätigt werden muss, kannst das so eigentlich vergessen.
Dann sind wir wieder beim fhem-gesteuerten Taster, das ist schlauer...

#######################

Conclusio:

pro 0,33-Getränk (ohnehin eine unsägliche dämliche Gebindegröße)

=> 100% Ack

Ich helfe dir gerne weiter.


Als erstes müssten wir mal versuchen, den Programmcode an sich zum laufen zu bekommen, damit wir sehen ob das Pairing überlebt, oder eben nicht.

Ich schlage folgendes vor:
Grundlage:
https://github.com/skorokithakis/gr8w8upd8m8

Den Code werfen wir mal testweise an und modifizieren ihn entsprechend.

Feel free to use processor.weight to do whatever you want with the calculated weight

Das finden wir im Skript in Zeile 299

print processor.weight

Anstelle des print nehmen wir eben urllib.urlopen, und lassen die Variable fhem mit processor.weight bereichern. Wir packen jede Waage in ein eigenes Config-File. Darin verpacken wir auch ein entsprechendes setreading für fhem, dass jede Waage auch im richtigen Reading landet. Evtl. auch Gewicht voll / leer, für alle Fälle.


Imho ist vieles aus dem Skript für unsere Zwecke eher unnötig. Z.b. verstehe ich den Kalibrier-Prozess nicht. Wenn er dazu dient, das Eigengewicht beim Start auf 0 zu setzen, können wir ihn getrost in die Tonne kloppen, da wir ja von einem drauf stehenden und angeschlossenem vollen Fass Bier ausgehen wollen.
Das sollte also keinesfalls als Standard 0 interpretiert werden


Schreib mich mal per PN an
Ich denke, das ganze sollten an einem oder zwei Wochenenden lösbar sein

Können wir gerne bei mir machen, dann nehmen wir halt kein Fass derweil sondern eine Kiste.

[Rince]

Für interessierte Mitleser:

Tomster und ich werden uns nächste Woche diesbezüglich treffen, dann sehen wir zusammen weiter.
Persönlich bin ich sehr zuversichtlich

@Tomster
Habe mir zur Sicherheit ne 4x Relais Platine bestellt damit wir potentialfrei schalten können, wenn nötig. 

[tomster]

Prima! Nach sowas Ähnlichem hab ich gestern auch schon gegooglet. Ich wollte aber ein Aufsteckboard für den Pi finden, das Relais und 1-wire an Bord hat UND halbwegs von FHEM unterstützt wird. Bin aber bislang noch nicht fündig geworden...

[Rince]

Kurzes Update:
Raspi 2, altes Wheezy

Ich bekomme mit dem Python Skript die Adresse (00:25:A0:40:5C:28)
Kann die auch direkt dem Skript mitgeben, dann wird nicht vorher nach anderen Boards gesucht

Im Moment sieht es so aus:
Skript starten
Kontakt überbrücken
Drauftreten
Runtergehen
Messung bekommen
dbus.expection error
Skript bricht ab

(Man kann auch zuerst den Kontakt überbrücken, dann das Skript starten => macht es einfacher; fhem muss einfach zuerst das Relais anziehen und loslassen, dann das Python Skript anwerfen)

Schlussfolgerung:
1. Betrieb mit mehreren Wii-Fit Boards scheint stressfrei zu sein (halt immer der Reihe nach )
2. Muss das Python Skript umbauen, dass die Kalibrierung nicht erfolgt
3. Die Messung muss kontinuierlich ausgegeben werden (im Sinne von: bevor man die Zahl sieht, muss man wieder runter gegangen sein)
4. dbus evtl. fixen

Das mit dem dbus Fehler betrachte ich grade als kosmetisches Problem; ich kann dennoch messen und anschließend wieder das Skript anwerfen, es wird also nix blockiert so wie es aussieht.
(apt-cache showpkg bluez => 4.99-2)
Evtl. brauchen wir noch eine ältere???

Schaue mir jetzt mal an, was bei dem beerfridge Skript anders ist

Das Pairing Problem halte ich für einstweilen gelöst

[Rince]

Der Rest ist auch gelöst.
http://makezine.com/projects/create-raspberry-pi-smart-beer-fridge/

Das wiiboard_test.py Skript macht genau das, was wir wollen


Ohne dBus Fehler

Die Messung schwankt bei meinem Testgewicht zwischen 5,216312 Kg - 5,3841414 Kg => mitthin 167 Gramm


Zum Schnaps abmessen also absolut untauglich, um rauszufinden ob noch ne Mass im Fass ist, sollte es gut reichen

=> ich baue dem Skript die Kommunikation zu fhem ein, eine Messung reicht, und die Angabe in kg

Alternativ lassen wir das Skript am Leben und lassen es kontinuierlich Daten an fhem senden. Das dürfte dem Relais viel Arbeit sparen. Vorausgesetzt, wir können auch die 2te Waage gleichzeitig nutzen.

@Tomster
Wann bekommen wir die 2te Waage?

[tomster]

Huii Rince,

du bist ja schneller als die Feuerwehr! Klingt ja alles seeehr vielversprechend. Kannst Du einen Unterschied in der Messung feststellen, wenn Du das Gewicht an unterschiedlichen Stellen auf dem Board platzierst? Hast Du Dich selbst (oder was mit ca. Fassgewicht) auch schon Mal gewogen, bzw. bleibt da die Differenz auch bei so geringen Abweichungen?

Zweite Waage hängt irgendwo beim Hermes-Versand. Die haben die wohl schlechteste Versandlaufzeit von allen. Das Paket wurde letzten Donnerstag abgeschickt und eine Statusabfrage gerade eben spricht von  "01.12.2015 05:53:00: Die Sendung wurde im Hermes Logistikzentrum sortiert." als letzte Meldung. Es hat also bis jetzt knappe 25km vom Absendeort bis nach Fulda geschafft...
Ich hoffe aber dennoch, dass das Board diese Woche noch kommt.

Die Kabel sind dann gleich drangelötet. Soll ich gleich irgendwelche Stecker/ Buchse vorsehen, oder bevorzugst du Freiluftverkabelung?

P.S. Schnaps gehört eh getrunken und nicht gemessen. Halt, das gälte für Bier eigentlich auch...

[Rince]

Glückstreffer.
Wer kann schon ahnen, dass das 2te Testskript problemlos läuft 
Ich hab mich gewogen, aber nur 1x. Dann bin ich erschrocken und wieder runter 

Morgen erweitere ich das Skript mit dem Netzwerkcode.


Die Verkabelung, hm, da halte ich mich raus
Sauberer wäre sicherlich ne Buchse im Gehäuse. Aber für den Moment tut es die andere Lösung auch. Jedenfalls, bis der erste im Eifer des Gefechts mit dem Fuß unsere Konstruktion beim Faßwechsel über den Haufen schiebt

Ich denke, das ein oder andere Bier wird da schon fließen müssen bis es gut läuft 


Wie wollen wir das in fhem darstellen?
Einen Dummy:
Faß_1
Readings:
aktuelles Gewicht
berechneter Füllstand (=aktuelles Gewicht - Leergewicht)
verbleibende Halbe (berechneter Füllstand / 0,5 abgerundet auf 0,5)

Als Attribute Leergewicht und Voll in kg? (Oder auch als Reading?)

Und, wo hinterlegen wir diese Daten? Ich tendiere dazu, sie direkt in fhem anzulegen, nicht im Config-File vom Skript.
Das ganze lassen wir loggen.


Dann ein Graph dazu, der als gefülltes Liniendiagramm einfach den Füllstand anzeigt

Für jedes Fass natürlich

[tomster]

Die Verkabelung, hm, da halte ich mich raus
Sauberer wäre sicherlich ne Buchse im Gehäuse. Aber für den Moment tut es die andere Lösung auch. Jedenfalls, bis der erste im Eifer des Gefechts mit dem Fuß unsere Konstruktion beim Faßwechsel über den Haufen schiebt

Ich denke, das ein oder andere Bier wird da schon fließen müssen bis es gut läuft 

OK, ich schua Mal, welche Steckerarten gut passen könnten.

Wie wollen wir das in fhem darstellen?
Einen Dummy:
Faß_1
Readings:
aktuelles Gewicht
berechneter Füllstand (=aktuelles Gewicht - Leergewicht)
verbleibende Halbe (berechneter Füllstand / 0,5 abgerundet auf 0,5)

Als Attribute Leergewicht und Voll in kg? (Oder auch als Reading?)

Und, wo hinterlegen wir diese Daten? Ich tendiere dazu, sie direkt in fhem anzulegen, nicht im Config-File vom Skript.
Das ganze lassen wir loggen.

Ja, so hab ich mir das in etwa auch gedacht. Dummy mit den Werten und die "Festwerte" als Attribute. Dann kann man die auch Mal anpassen, falls z.B. an der Anlage Mal was geändert wird. Wenn das dann noch aus FHEM heraus an das Script übergeben werden kann, wär's freilich am schönsten.

Die Anzeige brauch ich eigentlich gar nicht als Graph, zumindest nicht zwingend auf der FHEM-Oberfläche. Ich möchte die Anzeige mit FTUI realisieren. Ich mag das Frontnend und viel wichtiger: kenn mich damit aus

[Bennemannc]

Hallo,

Ihr treibt da aber einen netten Aufwand. Ich habe so etwas (nicht für fhem) sondern für die Gasflasche im Wohnmobil gebaut - allerdings mit einer Wägezelle. Das ist eine Wiederstandsbrücke die je nach Gewicht sich ändert. Die abgegriffene Spannung habe ich damal in eine fertige Auswerteeinheit von Conrad geschickt - sollte man aber auch an einen Arduino, Raspberry und Co senden können.

Gruß Christoph

Trotzdem - klasse Idee, habe auch noch ein Board rumliegen - vielleicht komme ich da nochmal auf Euch zurück 

[Rince]

Ich hab davon 0 Ahnung
Aber bin gerne bereit dazu zu lernen.

So ein Füllstandsgraph hätte schon was
Vor allem könnte man dann schön sehen, zu welchen Zeiten viel geht, wann es ruhiger ist etc...

Ich kann mir nicht vorstellen, dass FTUI keine Graphen kennt? Da sollte doch mit Javaskript und so der Bär steppen, oder?


Lass uns darüber quatschen, wenn das 2te Board da ist.


Ansonsten, bezüglich der Steckverbinder:

Wie wäre es, einfach Westernstecker zu nehem?
Oder Mono Klinke?
Meine Angst ist tatsächlich, dass wer beim Fäßerwechsel die Waage wegschubst. Mono Klinke rutscht halt dann raus. Wieder reinstecken und gut ist.


@Bennemannc
Ich werde das ganze im Lauf der (nächsten) Woche ins Wiki stellen (wenn ich den Code erweitert habe). Ist das ok?