Hallo zusammen 
(Jo , ich schon wieder) mit dem nächsten Problem.
Also ich hab den GOK Senso4s plus installiert. Die Ansteuerung per Senso App reibungslos. MAC Adresse wird auch im Dashboard erkannt, aber der Ausgabewert ist NaN%. Und im NodeRed hab ich gesehen, dass in der Exec ein Fehler (Error) ausgegeben wird. Ich hoffe wir finden den Fehler durch die Bilder. 
Hallo Zusammen,
hat hier noch jemand das Problem?
Ich habe mit 2.0.4 und 2.0.6 auch das Problem gehabt, habe jetzt tagelang mit meinem virtuellen Freund gerätselt, analysiert und herausbekommen, dass es tatsächlich mit der Verbindung zur Waage und dem connecten zutun hat.
Hat hier jemand noch weitere Lösungen, oder soll ich mal meinen Schrott hier posten?
@range4200t @Vincent ???
Gruß
Peter
Hi,
ich könnte durchdrehen. Heute wollte mich mich daran machen meine zweite GOK Waage ins Node-Red zu integrieren, also zum Testen nochmal das neue Skript mit der “anderen” MAC-Adresse durchlaufen lassen.
Ich dachte mir, teste mal ob es weiterhin funktioniert.
Das Ergebnis: zweite Waage wird nicht gefunden. Test mit der ersten Waage erneuet durchgeführt: keine Ergebnis.
Ich hab mir jetzt den Asus BT-540 bestellt, ich hoffe das bring Besserung.
Stay Tuned!
Hab jetzt mal die Waage plus Gasflasche raus genommen, um eine direkte Verbindung zum Rechner - VanPi - Waage zu schaffen. Hilft nichts. Die MAC wird erkannt, aber Ausgabe ist nur (NAN %). Keine Ahnung wo da der Hund sitzt.
Gruss Egon
Hi ich bin gerade wieder im WoWA und kann ein bissl spielen.
Also als allererste Empfehlung, definitiv ein BT Dongle besorgen.
Ich habe mir den ASUS BT540 geholt, damit hab ich immer kontakt zu den Waagen. Tatsächlich empfehlen Karl und Vincent das auch in der Doku;)
Sofern alles bei mir funktioniert, gebe ich alle Infos hier zusammengefasst in den Thread. Um weiterzukommen muss ich halt immer im Wowa sein und der steht 200km von uns entfernt.
Peter
Hallo zusammen,
ich habe das gleiche Problem. Im BMS wird NaN% angezeigt. In Node Red wirft die EXEC über ein Debug-Node aus: msg : Object { topic: „“, _msgid: „e7b400ded95b0af7“, payload: „“, creme: object }
Außerdem bekomme ich unter python3 Pekaway/ble_py/goksenso4.py -d MAC
Traceback (Most recent call last):
Und dann etliche Informationen von files mit dem Hinweis 354 in Experte Return usw.
In einer älteren Version vom VanPi lief alles einwandfrei.
Gruß
Ich habe jetzt eine alte Version genutzt und die Gok senso4s 2-fach eingebunden, im Anschluss habe ich den Flow BLE_Connection gesichert und in einer 2.0er Version importiert. Vor dem importieren habe ich den vorhanden deaktiviert. Jetzt werden mir die Werte korrekt angezeigt.
Ich werde es auch noch einmal mit einer aktuellen Version ausprobieren.
Gruß
Ingo
Interessant Was da wohl verändert wurde?
Jedenfalls kann ich keinen BT Dongle einsetzen. Denn dann hab ich keinen USB mehr frei auf dem Core. 
Also müsste es eine Lösung wie die Deine sein. 
Gruss Egon
Hallo,
ich habe es jetzt mit der 2.0.8 Version versucht, da funktioniert es nicht mehr. In der 2.0.0 geht es aber noch.
Vielleicht können Vincent und Karl Licht ins dunkle bringen
Ich bleibe jetzt erstmal bei der 2.0.0
Gruß
Ingo
Hey, funktioniert es mit dem ASUS USB-BT540 oder lieber den ASUS USB-BT500 nehmen?
@Vincent Hallo Vincent,
ich hab mir auch son Teil zugelegt, leider habe ich den Post zu spät gelesen. Ist ja sicherlich noch keine Lösung gefunden
Ich habe auf meinem Test System die V2.0.9
Beim Scan findet das System auch die Mac Adresse, die exec node gibt error 1 aus.
geb ich den Befehl aus der exec node auf der Konsole ein, kommt das:
pi@pekaway:~ $ python3 pekaway/ble_py/goksenso4.py -d E8:90:F1:27:62:19
Traceback (most recent call last):
File "/home/pi/pekaway/ble_py/goksenso4.py", line 30, in <module>
child.expect("Characteristic value was written successfully", timeout=1)
File "/home/pi/.local/lib/python3.11/site-packages/pexpect/spawnbase.py", line 354, in expect
return self.expect_list(compiled_pattern_list,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/pexpect/spawnbase.py", line 383, in expect_list
return exp.expect_loop(timeout)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/pexpect/expect.py", line 179, in expect_loop
return self.eof(e)
^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/pexpect/expect.py", line 122, in eof
raise exc
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
<pexpect.pty_spawn.spawn object at 0x7f9369aa50>
command: /usr/bin/gatttool
args: ['/usr/bin/gatttool', '-t', 'random', '-b', 'E8:90:F1:27:62:19', '--char-write-req', '--handle=0x000f', '--value=0100']
buffer (last 100 chars): b''
before (last 100 chars): b'connect to E8:90:F1:27:62:19: Function not implemented (38)\r\n'
after: <class 'pexpect.exceptions.EOF'>
match: None
match_index: None
exitstatus: 1
flag_eof: True
pid: 25870
child_fd: 5
closed: False
timeout: 30
delimiter: <class 'pexpect.exceptions.EOF'>
logfile: None
logfile_read: None
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0.05
delayafterclose: 0.1
delayafterterminate: 0.1
searcher: searcher_re:
0: re.compile(b'Characteristic value was written successfully')
pi@pekaway:~ $
Hast du eine Idee???
Gruß Arno
Das kannst Du dir überlegen. Ich habe den 540 und der funktioniert gut. 
Nur mit der Implementierung bin ich noch nicht weiter, da wir diese Jahr nicht so oft am WoWa waren.
Gruß
Peter
Hallo Vincent,
Hast du dich dem Thema schon angenommen, ich habe schon einiges versucht, auch mit ChatGpt aber es hat alles nix geholfen.
Wenn du keinen Gok sensor zur Hand hast, können wir auch per Teamviewer bei mir drauf schauen.
Gruß Arno
Also das mit dem 540er Dongle wird bei mir nichts. 
Nicht weil das nicht funktionieren würde, Sondern, weil ich den letzten USB Platz für die Autotherm reserviert ist, die ich demnächst bei Pekaway bestellen werde. Die anderen Ports sind mit GPS Maus und Victron-Geräte belegt. 
Witzig ist: Ich hab den Gok Senso 4 Plus. Auch der wird erkannt, aber der Wert gibt NaN -% aus. Dabei hab ich aber eine Frage. Wo wird (falls der Gok funktioniert), der Wert nachher sichtbar und ablesbar sein? Im VanPi Display zum Beispiel. Oder der App.
Ja eben da wird nan angezeigt, weil im Skript vermutlich ein Fehler ist, der Fehler Code, siehe oben
Der Wert wird nur auf der Config Seite angezeigt, den müsstest du dir doppeln und auf der Info Seite oder so anlegen
Moin zusammen,
im Ursprung wurden 2 von den 4Tankanzeigen in Info für die Gok Senso genutzt, das funktioniert nach dem Workaround aus dem Forum bis zur Version 2.0.0 bei den neueren Versionen nicht mehr. Es muss eine Änderung in den Flows oder in den Skripten gegeben haben.
Ich nutze seit ein paar Monaten einen Asus BT500 seitdem läuft die Verbindung zu den zwei Gok Senso stabiler als mit dem Pi Bluetooth.
Hey Ingo,
Du schreibst oben ich bleibe erstmal bei der 2.0.0.
Hast du jetzt ein Update gemacht?? Oder hängst du immer noch auf der alten Version?
Ich bin immer noch auf der 2.0 da der Wohni aktuell im Wintercamping steht und ich da ungern Remote dran rumfummeln möchte. Die Gok laufen aber wie gesagt auch stabil mit den Änderungen und mir wird in der App und in info die gaslevel zuverlässig in % angezeigt
nach 5 Stunden Basteln mit chatgpt diese Antwort
Klare Diagnose (nach allem, was du gezeigt hast)
gatttool ist für diesen Sensor auf deinem System faktisch unbrauchbarNicht „instabil“, nicht „falsch benutzt“ – strukturell inkompatibel.
Beweise aus deinem Log:
nRF Connect funktioniert 100 %
Services da
Notification kommt
Wert 0x4E korrekt
Linux / gatttool zeigt reproduzierbar
Function not implemented (38)
Command Failed: Disconnected
No notification received
→ klassischer BlueZ-Bug bei modernen BLE-Devices
Auch reine READs ohne Notify schlagen fehl
→ kein Timing-Problem mehr
Warum das so ist (kurz & ehrlich)gatttool ist seit BlueZ 5.64 deprecated
nutzt alte ATT-Requests
kommt **nicht klar mit:
LE Secure Connections
dynamischen Connection Params
mehreren Notify-CCCDs**
dein Senso 4S Plus ist zu neu
Android / iOS → modernes GATT
gatttool → Stand 2016
Was funktioniert nachweislich| Methode | Status |
|---|---|
| nRF Connect (Android) | |
| bleak (bei dir) | (BlueZ-DBus Timeout) |
| gatttool | |
| bluepy | (sehr wahrscheinlich) |
| ESP32 als Gateway | |
EMPFOHLENE LÖSUNG 1: bluepy (minimaler Aufwand)bluepy nutzt direkt BlueZ-HCI, nicht gatttool.
sudo apt update
sudo apt install -y python3-bluepy
Test:
python3 - <<'EOF'
from bluepy.btle import Peripheral
p = Peripheral("E8:90:F1:27:62:19", addrType="random")
val = p.readCharacteristic(0x000e)
print(val[0])
p.disconnect()
EOF
Erwartet:
78
(0x4E)
EMPFOHLENE LÖSUNG 2: ESP32-Gateway (professionell)Wenn das System dauerhaft laufen soll:
ESP32 liest Sensor
schickt Wert per MQTT / HTTP
Pi muss kein BLE mehr können
Das ist die Industrie-Lösung.
Warum ich dir jetzt NICHT weiter an gatttool herumbastlewir haben alle Workarounds ausgeschöpft
dein Sensor funktioniert
das Linux-Tool nicht
Weiteres Debugging wäre Zeitverschwendung.
Klare Empfehlung (ehrlich)
Vergiss gatttool für diesen Sensor.
Entweder:
bluepy (5 Minuten)
oder ESP32
Sag mir jetzt bitte:
Soll ich dir bluepy-Code exakt für den Senso 4S Plus schreiben?
Oder willst du ESP32 + MQTT?
Ich übernehme den nächsten Schritt komplett
fals @Vincent noch ne andere Möglichkeit hat gerne her damit
schönes WE
Gruß Arno