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?

[tomster]

Ich hab das mit dem Graphen eher auf das FHEM-WebFrontend bezogen. Da wird ausser mir sicher kein anderer Mensch reinschauen...
Mit Plots von Werten auf dem FTUI hab ich mich in dem Zusammenhang noch nicht beschäftigt.
Aber Du hast Recht. Es kann schon mehr als Sinn machen, wenn man die Daten als Graphen ausgeben kann.
Egal ob man damit die bierumsatzstärksten Monate/ Tage/ Uhrzeiten oder sonstwas angezeigt bekommen will.

6,3mm-Klinkenbuchsen hatte ich sogar noch rumliegen. Waren mir aber zu groß für das Gehäuse. Ich schau morgen Mal nach 3,5mm oder so.

[tomster]

So, 2. Board ist eben überraschenderweise angekommen. Laut Online-Abfrage sollte das Paket noch in Augsburg sein... Naja, wurscht.

Ich schau, dass ich heute irgendwie noch in einen Klinkenstecker-Laden komme.
Für den Unterbau hab ich mir Folgendes gedacht:

1 Plexiglas- oder Dibondplatte (muss ja glatt, nicht saugend & abwischbar sein, sagt der Herr Ordnungsamt; zudem ist beides vorrätig), die man pro Board in 4 Streifen á 100mm x 450mm schneidet. In 2 Streifen jeweils 2 Löcher mit 55mm Durchmesser für die Füße bohren und die Lochstreifen auf die anderen Kleben. Damit wird der Abstand zur Wand vorgegeben und die Boards stehen nicht direkt auf dem Boden (Hygiene beim Wischen).

Auf die Boards würde ich eine Holzplatte spaxen, auf die mit Leisten die Fassposition vorgegeben ist; quasi V-förmig, so dass sich das Fass beim Draufstellen fast selbst zentriert.

Zudem bin ich am Überlegen, ob man nicht sogar eine RasPi Zero in die Boards/ eins der Boards integrieren könnte.  Strom wäre ja schon da und die Bildübertragung ginge evtl. auch über wireless-HDMI oder so...

[Rince]

Ich würde ja nach wie vor ein Tab hinter die Theke hängen.

Aber das besprechen wir in Ruhe wenn ich komme um das 2te Board zu holen. Vielleicht morgen?


Btw,
wirf mal einen Blick auf den Anhang

Hier sehen wir, quck´n dirty, 2 Balkendiagramme

Der Rote ist das aktuell gemessene Gewicht (brauchen wir letztlich in der Grafik für nix, sieht im Moment einfach bunter aus
Der Blaue ist immer 2 weniger als der Rote.

Habe ich auf die Schnelle mit einem DOIF gelöst, welches dann auch den State vom Dummy setzt. Den könnten wir sicher noch mit sprintf oder so auf weniger Nachkommastellen runterbrechen, will aber jetzt erst mal nach Hause fahren

Code Auswählen Erweitern


Internals:
   CFGFN
   NAME       Fass_1
   NR         43
   STATE      1.96893443464
   TYPE       dummy
   Readings:
     2015-12-02 17:27:56   Füllstand      1.96893443464
     2015-12-02 17:27:56   Gewicht         3.96893443464
     2015-12-02 16:56:57   Leergewicht     2
     2015-12-02 17:27:56   state           1.96893443464
Attributes:
   room       Kühlung


[Rince]

Ach ja, die Werte kommen übrigens von dem Wii Fit Board.
Die Konfiguration wurde aus einem Config-File ausgelesen, die Daten werden so ca. alle 10sec  an fhem geschickt.

Anders ausgedrückt:
Ich denke ich bin fertig.


Wir müssen fhem nur noch beibringen ein Relais zu schalten fürs BT Pairing und dann das Skript lostreten.


Das Config File besitzt lediglich 3 Items:
BT Adresse vom Wii Fit Board
IP Adresse vom Fhem-Rechner mit Portnummer
Befehl für das Setreading vom entsprechenden Device, in dem Fall vom Dummy Fass_1

So gesehen sehr wartungsarm

[tomster]

Servus Rince,

das mit dem Zero Pi war auch eher so ein schneller Gedanke

Morgen passt schon. Ich bin zwar heut zu nix gekommen, aber vielleicht zwick ich mir morgen einen Besuch beim Apotheker Conrad in der Mittagspause ab. Gelötet ist das ja gleich. Welches Relaisboard hast Du denn verwendet? Wenn's das is, das ich meine, dann müsste es sogar auf das Gehäuse geschraubt werden können. Drunter passt wohl nicht ganz.

Die Einbindung in FHEM schaut wirklich schon sehr gut aus! Dann schau ich Mal, dass ich das auch nach FTUI umsetze. So ein 20€-Monitor ist heute mit der Post gekommen. Der Pi2 auch.

[Rince]

Oh, irgend so ein China 4x Relais Board mit Artikelstandort Deutschland. Artikelnummer 391289172929.
Kommt als Warensendung morgen oder übermorgen.

[Rince]

Beginn eines Wiki Eintrags:
http://www.fhemwiki.de/wiki/WiiFit_Waage

Wie wollen wir das mit dem Relais lösen?
Gibt mehr Möglichkeiten:
* Wir kümmern uns von Hand in fhem darum, dass vor dem Skriptstart das Relais kurz angezogen wird
* Wir basteln ein Start-Skript dafür, das das Relais anzieht bevor das Skript aufgerufen wird
* Wir bauen es in dem Python Skript ein, so dass es den Befehl über FHEM absetzt, bevor der Pairing Prozess gestartet wird

Und, 2 Fragen:
Wollen wir es beenden, wenn ja, wie???
Wie wollen wir es starten? (mit ´nem Timer nach global:initialized?)

[Rince]

Ok.
Nicht hübsch, aber effektiv:

Code Auswählen Erweitern

ps -ef | grep "python" | awk '{print $2}' | xargs sudo kill
Sollte alle laufenden Python Skripte beenden

Dann definieren wir ein cmdalias mit grob folgendem Inhalt:

1. Alle Python Skripte in den Wind schießen
2. Etwas warten
3. Fass 1 Relay an für 0.5
4. Skript für Fass 1 starten
5. Etwas warten
6. Fass 2 Relay an für 0.5
7. Skript für Fass 2 starten

Wem die Python-metzgerei zu grob ist:

Code Auswählen Erweitern

ps -ef | grep "python script_name" | awk '{print $2}' | xargs sudo kill
Macht aber nur Sinn, wenn die Skripte unterschiedliche Namen haben. Waage1.py und Waage2.py z.B.

[tomster]

Servus Rince!

Den Teil hier in Stavros' Tutorial hast Du auch gelesen, oder? Damit soll das Pairing permanent möglich sein...

HUGE EDIT: I have finally managed to get the Wii Board to successfully (and permanently) pair with my Ubuntu computer. Here are the steps:

    sudo apt-get install build-essential libdbus-1-dev check checkinstall to install the dependencies.
    apt-get source bluez to get the source.
    Apply this https://github.com/pcacjr/bluez/commit/c70a4afe4328053f462d8e30a0a787245aa7b948 to actually get it to recognize hex pin codes.
    ./configure --enable-test, make
    sudo checkinstall to create a .deb you can remove after pairing.
    Restart your computer/bluetooth services/etc.
    ./test/simple-agent hciX ##:##:##:##:##:##, you need to change hciX to whatever your Bluetooth adapter is (usually hci0, find it with hcitool dev). The hashes are the Balance Board's Bluetooth address.
    Your pin is now $FFEEDDCCBBAA, where AA:BB:CC:DD:EE:FF is your Bluetooth adapter's bluetooth address. Just reverse the order of the octets, so 01:23:45:67:89:AB becomes $ab8967452310.
    Your balance board will pair, and you have to immediately connect to it with python gr8w8upd8m8.py ##:##:##:##:##:##, or it might not pair.
    If you missed the connecting step above, run ./test/simple-agent hciX ##:##:##:##:##:## remove and try again.
    To trust the device so it will connect in the future, run bt-device --set ##:##:##:##:##:## Trusted 1

Hopefully that will work for you, let me know in the comments!

Das Disconnect-Problem bleibt aber wohl...

[Rince]

Hatte ich gelesen ja
Da stand noch drüber, dass es ein ziemlich einfacher Hack sei, der funktionieren kann oder auch nicht.
Und, was schlimmer ist, du musst die Waage, wenn sie disconnected ist, dennoch aktivieren. Das geht wieder durch drücken... nicht vom roten Knopf, sondern vom weißen. Damit hätten wir quasi nix gewonnen.

Ich Depp muss jetzt erst mal 3,5mm Klinkenstecker suchen oder auftreiben...
Sonst kann ich ja nicht an meine Relaisplatine 

[tomster]

Hatte ich gelesen ja
Da stand noch drüber, dass es ein ziemlich einfacher Hack sei, der funktionieren kann oder auch nicht.
Und, was schlimmer ist, du musst die Waage, wenn sie disconnected ist, dennoch aktivieren. Das geht wieder durch drücken... nicht vom roten Knopf, sondern vom weißen. Damit hätten wir quasi nix gewonnen.

OK, dann hätten wir nicht wirklich etwas gewonnen. Stümmt...

Ich Depp muss jetzt erst mal 3,5mm Klinkenstecker suchen oder auftreiben...
Sonst kann ich ja nicht an meine Relaisplatine 

Oh, Mann, ich Depp. An das hab ich natürlich nicht gedacht. Hätt ja bloß 2 Stück mehr mitnehmen müssen...

[phel]

Hallo zusammen,

arbeite mich auch gerade in das Thema ein, würde gerne meine Personenwage ersetzen. Daher möchte ich eigentlich folgende Funktionalität haben:
- Start durch betätigen des Frontschalters
- Nullung bei initialisierung
- Ausschalten nach Messung

Da ich meinen usb bt dongle für den rpi nicht mehr finde  nutze ich eben nun übergangsweise ein ubuntu notebook. Beim Kampf mit dbus & bluez bin ich über folgende informationen gestolpert:

The bluez bluetooth stack is the official linux bluetooth stack which is provided by all major distributions. Since version 4.101 it includes fixes so Nintendo devices can be paired with linux hosts. If you use an older bluez version, you may still be able to use Nintendo Wii / Wii U devices, but you cannot pair them.

https://dvdhrm.github.io/xwiimote/

Vermutlich für eure Anwendung nicht notwendig, finde es aber die saubere Variante wenn nicht jedes mal der rote knopf betätigt werden muss. (Könnte bei mehreren Boards in einem Raum auch durcheinander geben).
inzwischen habe ich das board erfolgreich gepaired und bekomme werte, jetzt muss ich noch euren script für meine bluez&dbus anpassen.

Grüße
phel

[Rince]

Hi,
klingt nicht schlecht. Aber dann musst du den vorderen Button drücken, um die Verbindung wieder aufzubauen, oder?
Ist für eine Badwaage völlig in Ordnung, in unserem Fall würde es nicht helfen. Deshalb ja das Relay, welches fhem selber schalten kann