[Gelöst] 74_XiaomiBTLESens.pm per sshHost überfordert Pi Zero W?

[iceman]

Hallo zusammen,

ich frage mittels sshHost 4 Xiaomi Temperatur Sensoren hab. Diese erreicht mein FHEM-Server über einen Raspberry PI Zero W. der komplette Weg sieht also wie folgt aus:

FHEM-Server --(LAN)--> FritzBox --(WLAN)--> Fritz-Repeater --(WLAN)--> PI Z w --(BTLE)-->  4x Xiaomi Senoren

Das Abfrage Intervall habe ich für 2 Sensoren auf 300 und bei 2 Sensoren auf 600 gesetzt. Wenn ich mit nun mittels Putty auf auf meine Raspberry PI Zero W verbinden möchte klappt das nur manchmal. den Usernamen kann ich meist noch eingeben. bei der Authentifizierung per Key belibt er meist schon hängen.

Die Ping Zeiten liegen so zwischen 8-40ms.

Auf dem Raspberry läuft stretch mit der Bluez Version 5.43

Ich habe einen weitern PI-Zero W im Netz, den komplett gleich aufgesetzt habe der allerding nur 2 Sensoren anspricht und nicht über den Repeater geht. Diesen kann ich stabil ansprechen.

Hat oder hatte jemand hier ein ähnliches Problem? Und kennt jemand eine Lössung bzw. eine Ecke wo ich mal schauen könnte?

Ich bedanke mich schon einmal für Euere Tipps.

[MadMax-FHEM]

Evtl. Verbindung zu schlecht, weil zu viele Zwischenstationen!!?

Ich habe einen ZeroW der locker 10 Sensoren abhandelt und kein Problem...

PI und Fritzbox sollen ja WLAN-technisch nicht die besten Freunde sein und dann noch mit Repeater...

Bei mir hängt fhem per LAN am Switch und dann direkt WLAN-AP (Unifi)...
Maximal per Mesh (nicht Repeater) an einem anderen AP (je nach "Laune" des ZeroW   )...

Lief bis gestern auf Jessie...
...ab heute auf Buster...

Gruß, Joachim

[iceman]

Hi MadMax,

sorry das hatte ich vergessen, Die Fritzbox und der Repeater sind ein Mesh Netzwerk. Aber das sich Raspi und Fritzbox nicht mögen ist mir neu...

[MadMax-FHEM]

Hab ich irgendwie "im Ohr"...

Auf jeden Fall bekannt, dass Fritzbox WLAN und ESPs "Probleme" haben...

Wieviele WLAN-Geräte hast du in Summe an der Fritzbox hängen!?

Weil (und das sollte im Forum zu finden sein) die Fritzbox wohl bei 20+ (nimm die Zahl nicht als in Stein gemeißelt   ) Geräten (langsam) in eine "Sättigung" kommt...

Ich kann nur sagen: ich denke nicht, dass es am Modul, ssh (generell) oder dem PIZeroW (generell) liegt...

Was steht denn im Log!?
Am besten verbose 5 bei den Snesoren.

Was steht in LAST_ERROR!?

Gruß, Joachim

[iceman]

Also folgende Fehler hab ich wie gesagt nicht kontinuierlich aber doch so, dass ich nicht lang im Log suchen muss.

packet_write_wait: Connection to <IP> port 22: Broken pipe
packet_write_wait: Connection to <IP> port 22: Broken pipe
packet_write_wait: Connection to <IP> port 22: Broken pipe

Timeout for FHEM::XiaomiBTLESens::ExecGatttool_Run reached, terminated process 4994

WLAN Geräte habe ich mometan "nur" 12 im Netz.

[MadMax-FHEM]

packet_write_wait: Connection to <IP> port 22: Broken pipe

Naja, da würde ich trotzdem stark auf Netzwerk tippen...

Evtl. mal einen "Dauer-Ping" eine Weile laufen lassen und sehen, ob es da "Aussetzer" gibt...

Hängen noch andere Geräte (auf die du dich einloggen kannst) am Mesh/Repeater!?
Dort mal probiert!?

Korrekt konfiguriert!?

EDIT: 12 generell oder "nur" am Mesh/Repeater!?

EDIT: ich habe weit über 50 im Netz und knapp 40 davon per WLAN... Aber auch keine Fritte (naja gut als "Telefon" und "Internet" Box   )...

Gruß, Joachim

[iceman]

Generell nur 12 Geräte am Netz und die Angabe 8-40ms war schon über ein Dauerping ermittelt. Messperiode ca. 30 Minuten.

[MadMax-FHEM]

Hmm, sieht nicht so schlecht aus...

Was sagt 'top'!?

Macht der ZeroW noch andere Dinge!?

Weil normalerweise sollte es ihn nicht aus der Bahn werfen, wenn ab und an mal per ssh eine BT-Abfrage gemacht wird...

Mein ZeroW macht genau nur das...

EDIT: hast du die Lite-Version von Raspbian drauf!? Hast du memory-Split auf 16MB!?

Gruß, Joachim

[iceman]

Der Pi macht nix anderes und auf der 8GB Karte hab ich die stretch Lite Variante installiert.

Was meinst Du mit 16MB Memory Spilt?

Ich habe jetzt mal FHEM ausgemacht bzw die sshHost abfrage und siehe da, nun ist die Putty Verbindung stabil. Kann es sein das FHEM trotz der Intervalle von 300 bzw. 600 Sekunden meinen PI mit anfragen zuballert?

Mir fällt leider nicht ein, wie ich das eventuell mal überprüfen kann..

[Beta-User]

Falls du an einer Alternative interessiert bist: Ein ESP32 mit OpenMQTTGateway-firmware sollte auch in der Lage sein, die Daten zu empfangen: https://docs.openmqttgateway.com/#/ und https://docs.google.com/spreadsheets/d/1_5fQjAixzRtepkykmL-3uN3G5bLfQ0zMajM9OBZ1bx0/edit#gid=2126158079.
Ich nutze das z.B. für die runden Xiaomi-BT-Thermostate.

[iceman]

Das klingt doch nach einer guten Alternative.

ich schau mir das mal an. Mit ESPs hab ich noch nicht viel Erfahrung (Arduino schon) hast Du einen Tipp womit ich starten sollte?

[Beta-User]

Ich habe da einfach einen (eigentlich ein paar, weil ich testen wollte, ob man damit auch BT-Tags "lokalisieren" kann) NoName-ESP32 im fernen Osten bestellt (wie diese hier) und dann die binaries draufgeflasht. Nicht ganz nach der Anleitung hier: https://docs.openmqttgateway.com/upload/binaries.html#esp32, weil ich das ganze unter Linux gemacht habe. Die einzige "Spezialität" ist halt, dass man das Ding vorher/beim Flashen "Partitionieren" muß und die eigentliche firmware nur ein Teil der Daten darstellt, die man drauf macht.

Für nur BT sollte die "BLE"-binary passen: https://github.com/1technophile/OpenMQTTGateway/releases/download/v0.9.4beta/esp32dev-ble-firmware.bin

Das GW wird dann einfach ins lokale WLAN gehängt, mit einem MQTT-Server (ich nutze TYPE=MQTT2_SERVER) verbunden und via attrTemplate dann in einzelne BT-MQTT2_DEVICEs vereinzelt. Allerdings fehlt der Flower-Sensor noch in der attrTemplate-Sammlung, aber das dürfte ein lösbares Problem sein...

[MadMax-FHEM]

Was meinst Du mit 16MB Memory Spilt?

Du kannst je per raspi-config einstellen wieviel Speicher von den (knappen) 500MB für "Grafik" genutzt werden sollen.
Standard sind 64MB und Minimum eben 16MB...
Da du ja nur Lite hast (vernünftig   ) reichen die 16MB.
Ist bei mir Standard bei ALLEN PI, laufen ALLE ohne Grafik

(gut stimmt nicht ganz, ich habe einen PI4 als "Mini-Desktop"   der hat nat. mehr aber der hat ja auch 4GB   )

Ich habe jetzt mal FHEM ausgemacht bzw die sshHost abfrage und siehe da, nun ist die Putty Verbindung stabil. Kann es sein das FHEM trotz der Intervalle von 300 bzw. 600 Sekunden meinen PI mit anfragen zuballert?

Sollte nicht...
Weil: wozu

Außer du hast noch PRESENCE "Richtung" den PI o.ä. laufen...

Mir fällt leider nicht ein, wie ich das eventuell mal überprüfen kann..

nMap o.ä. auf "Dauerlauf"!?

Evtl. mal mit wireshark schauen was da so los ist...


Aber die ESP-Alternative ist ja auch einen Versuch wert...
...wenn allerdings (doch) was mit dem Netzwerk sein sollte, wird das dann verm. auch nicht klappen...

Viel Erfolg, Joachim

[Beta-User]

Aber die ESP-Alternative ist ja auch einen Versuch wert...
...wenn allerdings (doch) was mit dem Netzwerk sein sollte, wird das dann verm. auch nicht klappen...

Klar, ohne funktionierendes Netzwerk geht es nicht, und jeder ESP mehr ist "ein erhöhtes Risiko". (Wobei der 32 deutlich besser designed zu sein scheint wie der kleine Bruder ESP8266).

Der Vorteil gg. dem Zero W liegt allerdings darin, dass es ein "fire&forget"-Gerät ist, dessen OS man nicht ganz so zwingend wie bei einem "Rechner" wie dem Zero W up-to-date halten _muß_, und dass das Ding von vornherein das "losere" MQTT spricht. So bekommt man auch ohne gepinge mit, wenn das Ding nicht erreichbar ist, weil das WLAN zickt, und das als FHEM-Event direkt & "frei Haus" ...

[MadMax-FHEM]

Naja, wobei man halt (ehrlicherweise) auch sagen muss/sollte, dass man halt bzgl. OS-Updates bzw. von den "Schwachstellen"/"Bugs" (wegen denen es Updates gibt / bzw. die man einspielen sollte/muss) eher etwas erfährt, weil es eben einen einfachen Mechanismus gibt...
...und es keine "forget" Geräte sind...

Es gibt genauso Schwachstellen im unterlagerten ESP-OS (naja gut heißt: SDK), nur darum kümmert man sich nicht (wirklich: "forget" Gerät   ) und wenn doch, ist der Aufwand da was upzudaten oft (erheblich) größer...

Aber ja ich weiß schon was du meinst...

Gruß, Joachim

[Beta-User]

Klar, auch einen ESPxyz kann man kapern, wenn man Ahnung hat, wie. Und ein ESP32 hat vermutlich teils deutlich mehr Power/Speicher+++ als mein erster PC...

Von daher: Ja, auch diese Dinger sollte man regelmäßig updaten, was bei OMG leider nicht ganz so klickibunti ist wie bei einem Tamota oder Shelly (bin mal gespannt, wann da auch eine admin-Oberfläche kommt, mit der es geht...). Aber auch die kann man via Arduino-OTA updaten (ich bin trotzdem ein Freund von Kabeln, auch beim flashen ).

Da man aber in der Regel (noch) die ganze firmware tauscht, hoffe ich mal drauf, dass ich das merken würde, wenn meine OMG's plötzlich zum man-in-the-middle werden und in ferne Länder nach Hause telefonieren... Außerdem sind das immer noch "Exotendevices", da darf man auf "security by obscureness" hoffen .

[MadMax-FHEM]

Also "Exotendevices" würde ich nicht "unterschreiben"...
...wenn man eine Umfrage im Forum starten würde käme bestimmt raus, dass es hundert mal mehr ESP gibt als PIs oder andere "Rechner"...

Aber egal wie meinen/meinem ESP verbiete ich auf jeden Fall mal das "nach-Hause-telefonieren"

Aktuell habe ich ja nur einen mit selbstgebautem Sketch...

EDIT: und jetzt Popcorn!

Gruß, Joachim

[iceman]

Wenn ich aber die ESP nicht raus laß (ins Internet) und nur im lokalen LAN lasse ist das doch sicher oder übersehe ich da was?

[Beta-User]

Vermutlich relativ.....

[iceman]

Um aber zum eigentlichen Thema zurück zu kommen.

Da, die Putty anbindung nur rumzickt, wenn ich die 4 Sensoren per sshHost abfrage, denke ich immer noch das es an der Sensorabfrage liegt. Könnte es sein, dass das Gatttool blockiert?

[MadMax-FHEM]

Gatttool blockiert, ja.

Aber seitens fhem ist das non-blocking ausgelagert...

Und jeder ssh-Zugang läuft in seiner eigenen "Umgebung", egal was ein anderer ssh macht...
...sofern der "Rechner" noch "Luft" hat...

Wenn also "etwas" (per ssh) den "Rechner" auslastet, dann merkt man das auch mit einem (weiterem) ssh-Zugang...

Daher ja die Frage was "top" so sagt...

Gruß, Joachim

[Jamo]

Hallo iceman,

Hat oder hatte jemand hier ein ähnliches Problem?

Ja, dass kenne ich, und hat meiner Meinung nach nichts mit dem 74_XiaomiBTLESens.pm per sshHost zu tun, sondern mit dem piZero und WLAN. Ich hatte das gleiche auch Jahrelang. Der ssh funktioniert ja an sich, und man bekommt ja auch die Werte von den XiaomiBTLE - Sensoren geliefert , aber die ssh Verbindung nach dem Login steht nur kurz. Man kann sich einloggen, aber kurz danach bricht die Verbindung ab.

Du kannst einen Ethernet dongle (ein paar euro bei Amazon) an den USB Port anschliessen, und dann funktioniert es mit Kabel

Oder auf einen Raspi 3 umsteigen, da gehts auch. Die PiZero habe ich bei mir alle aussortiert, über WLAN haben die nie funktioniert. Die gleiche SD Karte in einen Raspi 3 gesteckt, und schon gehts.

PS: Habe gerade gelesen, das Du sagst, der PiZero, der nicht über den Repeater geht, funktioniert - Ich habe auch einen 2-ten WLAN access point (als Bridge, also über Eth kabel) mit dem gleichen WLAN namen aber anderer Kanal. Dass stimmt das der piZero nie weiss mit wem er sich verbinden soll. Meiner Meinung nach auf jeden Fall ein WLAN problem.

[MadMax-FHEM]

Habt ihr schon mal dran gedacht, dass einfach euer WLAN suboptimal ist!?

Ich habe 2 ZeroW und bei beiden frag ich Dinge per ssh ab...
...und kein Problem...

Parallel einloggen mit ssh: kein Problem...

Habe ich nicht und hatte ich noch nie: Fritzbox für WLAN...

Fritzbox macht bei mir (neuerdings) nur Internet und Telefon...

Gruß, Joachim

[Jamo]

Du hast bestimmt einen Ubiquiti/UniFi AP, habe ich auch schon mal ueberlegt.

[MadMax-FHEM]

Ja...

Aber hatte zuvor mit meinem Netgear Nighthawk (hätte ich nicht weg tun brauchen, der war für Standalone wirklich gut/jetzt ist nat. besser aber auch teurer: brauchte für ähnliche Abdeckung etc. 3APs...   ) und davor mit meinem D-Link auch keine Probleme...

Gruß, Joachim

[iceman]

So kleines Update und dann man ich das Thema zu.

ich bin letzte Woche auf OpenMQTTGateway per ESP32 umgestiegen. Die Messwerte kommen jetzt häufiger und es gibt auf diesen Wege keine Fehler mehr. Nun habe ich diese Woche ein FritzBox Update auf 7.20 bekommen und siehe da, nun ist der Statellit (RPi Zero) auch per SSH stabil zu erreichen.

Die SSH Anbindung wurde laut AVM changelog auch verbessert. Mein AVM Repeater der ja auch nicht dazwischen hängt läuft allerdings noch mit der alten FW 7.12

Momentan lasse ich beide Wege aktiv, da die OpenMQTTgateway Lösung momentan noch keine Batteriewerte mitliefert.