Hallo,
seit ca. dem 22. Oktober schmeist mein speedtest fast nur noch fehler und geht in den status failed ohne resultat.
Im Log sehe ich folgendes:
2020.10.26 23:11:34 5: starting speedtest
ERROR: No matched servers: 1746
2020.10.26 23:11:49 5: speedtest done
2020.10.26 23:11:49 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/32_speedtest.pm line 163.
Manchmal geht es mit dem Server, manchmal nicht. Habe auch schon etliche andere aus der Liste eingetragen, nix zu machen.
Via PC läuft es.
Fhem ist aktuell. Ich erinnere mich nicht, dass ich an dem Tag irgendetwas am Fhem Server verändert hätte.
Es lief über Jahre hinweg gut.
Abgesehen davon, das ich kein Freund von Speed-Test bin (Sie machen mir die Leitung zu sehr Dicht):
Bitte um mehr Daten .....
- IPv4 oder 6?
- Welcher Anbieter
- Welcher Server
- Welcher DNS-Server
Ich habe mit dem Speedtest immerhin eine Sonderkündigung bei Vodafone KabelDeutschland erwirken können. Seit dem Lockdown am 11. März ging nix mehr tagsüber.
Aber zurück zu den Daten:
Habe einen IPV4 Anschluss (Extra Option bei KD)
Server Liste:
7560 Frankfurt
1746 Frankfurt Vodafone
2398 Hamburg Studio Funk
4087 Norderstedt Wilhelm.tel
16688 Hamburg Highspeed-Check.de
31469 Telekom
Bisher habe ich immer 16688 verwendet und der lief super. vom PC aus geht es auch meistens. Ich habe die Befürchtung, dass das CLI Script irgendwie zu kleine Timeouts oder so hat. Also wenn die Werte der Leitung gerade ganz schlecht sind.
DNS Server muss ich die von KD nehmen. Das lässt sich nicht anpassen.
Manchmal geht der Test tatsächlich:
2020.10.27 02:05:00 5: starting speedtest
2020.10.27 02:05:39 5: speedtest done
2020.10.27 02:05:39 5: speedtest_SpeedtestDone: speedtest|24.833 ms|3.94 Mbit/s|29.51 Mbit/s
für eine 500/50 Mbit Leitung traufmhafte Werte :-(
Ich habe gesehen, das es kürzlich ein Update zum Speedtest gab. Es gibt jetzt die Option Ookla 0|1
Das scheint aber nur die Möglichkeit zu bieten ein anders Script zu nehmen?
Ich stehe jetzt gerade auf dem Schlauch: ist speedtest ein FHEM-Modul, ein externes Script oder ....
Grad noch mal geprüft, was ich am System gemacht habe...
ungefähr zu dem Zeitraum wurden die folgenden Pakete installiert:
Upgrade: freetype2-doc:armhf (2.9.1-3+deb10u1, 2.9.1-3+deb10u2), libfreetype6-dev:armhf (2.9.1-3+deb10u1, 2.9.1-3+deb10u2), libfreetype6:armhf (2.9.1-3+deb10u1, 2.9.1-3+deb10u2)
End-Date: 2020-10-23 09:54:56
Letztes FHEM update war am 2020-10-21_22:08:35 system change: update
Am 22. 10. ab etwa 21:15 schlägt der Test fehl.
So richtig passen die Daten nicht zusammen...
Es ist ein Fhem Modul das ein externes Script startet :-)
https://wiki.fhem.de/wiki/Speedtest (https://wiki.fhem.de/wiki/Speedtest)
ZitatERROR: No matched servers: 1746
ich würde sagen zumindest in diesem lauf gab es den server 1746 nicht.
lass das ganze mal ohne server angabe laufen und schau ob es dann stabil ist.
die ookla variante gibt sehr viel genauere werte bei schnelleren leitungen.
Ohne Server Angabe läuft es besser.
Allerdings sind die Ergebnisse nicht mehr so wirlich vergleichbar, da die Server selbst unterschiedlich schnell sind.
Ich lass das mal eine Weile laufen und schalte dann mal wieder auf einen einzelnen Server zurück.
Kann ich irgendwie mitloggen welcher Server bei jeder Anfrage genutzt wird? Unterstützt das Modul das?
Bei Verbose 5 wird das nicht ins log geschrieben.
nur in der ookla variante.
Nur um Sicherzugehen, Ookla ist eine Option für das Script oder wie ist das zu verstehen?
Ich sehe die Server nicht in den Logs oder als Reading und habe die Option auf 1 gesetzt
du musst dann auch noch die ookla speedtest cli version installieren.
siehe wiki und hier: https://forum.fhem.de/index.php/topic,114118.0.html (https://forum.fhem.de/index.php/topic,114118.0.html)
Installiert, läuft super gut!
Ich melde mich mit Resultaten.
Danke noch mal!
läuft nach wie vor ohne Probleme. Habe nen festen Server verdrahtet.
Die Werte vom Download schwanken etwas mehr als vorher, kommen mir aber realistischer vor.
Jetzt sehe ich zumindest, dass es so gut wie immer nur am mikrigen upload liegt, wenn was nicht geht hier.
Die Serverliste wurde irgendwann letztens sehr eingeschränkt.
Mit einem festen Server (insbesondere Vodafone) war die Chance recht hoch, auf die Nase zu fallen.
Ich hatte mir irgendwann mal eine Version des Moduls zurechtgebastelt, die auch den Server und ein paar andere Dinge loggt die speedtest-cli ausspuckt.
Andre, schau doch mal ob du irgendwas davon übernehmen möchtest ;)
Hatte auch die Fehler mit dem alten speedtest Modul. Gibt es denn die angepasste für ookla als .pm ? Mit update all aktualisiert er nix von speedtest.
Hatte mir auch mal derweil die speedtest-cli gezogen und installiert:
https://github.com/sivel/speedtest-cli
Benötigt man beide Versionen? attr ookla ist auf 1 gesetzt im define.
Fehler bleibt weiterhin.
Welche Fehler?
Falsche/fehlerhafte Angaben/Messwerte?
Du musst schon den speedtest von ookla runter laden...
...um ihn benutzen zu können... ;)
EDIT: hier noch mal https://forum.fhem.de/index.php/topic,114118.0.html
EDIT: bei mir kam das speedtest-Modul mit ookla ganz normal mit dem update...
Gruß, Joachim
Habe es nochmal komplett neu gemacht. Irgendwie will sich das auf der Konsole wieder nicht korrekt installieren:
pi@FHEM-Server4:~ $ echo "deb https://ookla.bintray.com/debian ${DEB_DISTRO} main" | sudo tee /etc/apt/sources.list.d/speedtest.list
deb https://ookla.bintray.com/debian stretch main
pi@FHEM-Server4:~ $
pi@FHEM-Server4:~ $ sudo apt-get update
Holen:1 http://archive.raspberrypi.org/debian stretch InRelease [25,4 kB]
OK:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Es wurden 25,4 kB in 0 s geholt (29,4 kB/s).
Paketlisten werden gelesen... Fertig
E: Method https has died unexpectedly!
E: Unterprozess https hat einen Speicherzugriffsfehler empfangen.
E: Methode /usr/lib/apt/methods/https ist nicht korrekt gestartet.
E: Fehlschlag beim Holen von https://ookla.bintray.com/debian/dists/stretch/InRelease
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
pi@FHEM-Server4:~ $
Komme also garnicht erst zur Installation mit:
sudo apt-get install speedtest
Zeige uns mal den Inhalt:
cat /etc/apt/sources.list.d/speedtest.list
deb https://ookla.bintray.com/debian stretch main
Steht ja oben auch, das er die speedtest.list so anlegt.
pi@FHEM-Server4:~ $ echo "deb https://ookla.bintray.com/debian ${DEB_DISTRO} main" | sudo tee /etc/apt/sources.list.d/speedtest.list
deb https://ookla.bintray.com/debian stretch main
Ist aber ein Unterschied zwischen Teorie und Praxis ... deshalb meine Frage ...
Hast Du denn wirklich alles Nötige vorher installiert?
apt-get install gnupg1 apt-transport-https dirmngr
Auch den Key übernommen?
Ja alles gemacht :)
pi@FHEM-Server4:~ $ sudo apt-get install gnupg1 apt-transport-https dirmngr
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
apt-transport-https ist schon die neueste Version (1.4.10).
dirmngr ist schon die neueste Version (2.1.18-8~deb9u4).
gnupg1 ist schon die neueste Version (1.4.21-4+deb9u1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
pi@FHEM-Server4:~ $
pi@FHEM-Server4:~ $ export INSTALL_KEY=379CE192D401AB61
pi@FHEM-Server4:~ $ export DEB_DISTRO=$(lsb_release -sc)
pi@FHEM-Server4:~ $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $INSTALL_KEY
Executing: /tmp/apt-key-gpghome.GUCqGFhIKc/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 379CE192D401AB61
gpg: Schlüssel 379CE192D401AB61: "Bintray (by JFrog) <bintray@bintray.com>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: unverändert: 1
pi@FHEM-Server4:~ $
pi@FHEM-Server4:~ $ echo "deb https://ookla.bintray.com/debian ${DEB_DISTRO} main" | sudo tee /etc/apt/sources.list.d/speedtest.list
deb https://ookla.bintray.com/debian stretch main
pi@FHEM-Server4:~ $
pi@FHEM-Server4:~ $ sudo apt-get update
Holen:1 http://archive.raspberrypi.org/debian stretch InRelease [25,4 kB]
OK:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Es wurden 25,4 kB in 0 s geholt (29,4 kB/s).
Paketlisten werden gelesen... Fertig
E: Method https has died unexpectedly!
E: Unterprozess https hat einen Speicherzugriffsfehler empfangen.
E: Methode /usr/lib/apt/methods/https ist nicht korrekt gestartet.
E: Fehlschlag beim Holen von https://ookla.bintray.com/debian/dists/stretch/InRelease
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
pi@FHEM-Server4:~ $
Man kann sich auch einfach das fertige "Binary" runter laden (wie bei dem "alten" speedtest-cli).
Hier meine "Notizen" für einen Raspberry PI (allerdings Buster):
wget https://bintray.com/ookla/download/download_file?file_path=ookla-speedtest-1.0.0-armhf-linux.tgz
mv 'download_file?file_path=ookla-speedtest-1.0.0-armhf-linux.tgz' ookla-speedtest-1.0.0-armhf-linux.tgz
jaja, etwas "ungeschickt" ;)
Man kann bei wget auch angeben (-o ?) wie die Datei nach dem Runterladen heißen soll, dann kann man sich das "Umbenennen" sparen, bzw. kann man das auch lassen, dann halt beim "tar" entsprechend den richtigen Namen nehmen ;)
tar -xf ookla-speedtest-1.0.0-armhf-linux.tgz
sudo mv speedtest /usr/local/bin/
evtl. noch ein (konnte ich aber in meinen Notizen nicht finden):
sudo chmod +x /usr/local/bin/speedtest
Gruß, Joachim
Besten Dank, ich probier es mal und werde berichten.
Ok habs installiert.
Speedtest by Ookla
Server: IBH IT-Service GmbH - Dresden (id = 2495)
ISP: Deutsche Telekom AG
Latency: 6.86 ms (0.17 ms jitter)
Download: 168.40 Mbps (data used: 91.2 MB)
Upload: 41.33 Mbps (data used: 18.7 MB)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/265a5053-3e46-45b8-9c49-b5875325d724
pi@FHEM-Server4:~ $
Ändert sich denn nun was an dem define ?
define WEB_Speedtest speedtest 1800 31449
31449 ist der Server, woher bekomme ich nun die angepasste speedtest.pm (per Update kommt da nix.)
Weil den Fehler habe ich weiterhin.
2020.11.13 11:32:15 1: PERL WARNING: Use of uninitialized value $a[1] in pattern match (m//) at ./FHEM/32_speedtest.pm line 181.
2020.11.13 11:32:15 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
2020.11.13 11:32:15 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 213.
2020.11.13 11:32:15 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
hier noch mein list:
Internals:
DEF 1800 31449
FUUID 5c4b3baf-f33f-252b-cb5e-2ec6497ad89053ec
INTERVAL 1800
LOCAL 0
NAME WEB_Speedtest
NR 134
SERVER 31449
STATE Initialized
TYPE speedtest
READINGS:
2020-11-12 21:08:19 download 6.88
2020-11-12 21:08:19 ping 63.131
2020-11-13 11:32:15 state failed
2020-11-12 21:08:19 upload 44.84
helper:
Attributes:
DbLogExclude .*
DbLogInclude download,ping,upload
alias Internet Speedtest
disable 0
group DSL Geschwindigkeit
icon it_i-net
ookla 1
path /usr/local/bin
room 50-FritzBox-AVM
Besten Dank
Edit: Nach Reboot
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
2020.11.13 11:50:49 1: PERL WARNING: Use of uninitialized value $a[1] in pattern match (m//) at ./FHEM/32_speedtest.pm line 181.
2020.11.13 11:50:49 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
2020.11.13 11:50:49 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 213.
2020.11.13 11:50:49 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
Installiert ist es:
pi@FHEM-Server4:~ $ find . |grep speedtest
./ookla-speedtest-1.0.0-armhf-linux.tgz
./speedtest.5
./speedtest.md
./.local/bin/speedtest-cli
./.local/bin/speedtest
./.local/lib/python2.7/site-packages/speedtest.py
./.local/lib/python2.7/site-packages/speedtest_cli.py
./.local/lib/python2.7/site-packages/speedtest_cli.pyc
./.local/lib/python2.7/site-packages/speedtest.pyc
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info/WHEEL
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info/METADATA
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info/entry_points.txt
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info/RECORD
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info/top_level.txt
./.local/lib/python2.7/site-packages/speedtest_cli-2.1.2.dist-info/INSTALLER
./.config/ookla/speedtest-cli.json
pi@FHEM-Server4:~ $
Du hast das Paket jetzt vielleicht installiert bekommen, aber dein apt sagt dir was wichtiges, was du nicht einfach übergehen solltest:
Zitat
E: Method https has died unexpectedly!
E: Unterprozess https hat einen Speicherzugriffsfehler empfangen.
Das sollte bei dir Besorgnis wecken. Wenn das ein Pi ist, ist womöglich die SD-Karte defekt. Irgendwas stimmt ja mit deiner Installation nicht mehr.
Zitat von: Christoph Morrison
Das sollte bei dir Besorgnis wecken. Wenn das ein Pi ist, ist womöglich die SD-Karte defekt. Irgendwas stimmt ja mit deiner Installation nicht mehr.
Danke für den Hinweis. Wieso kommst du darauf, das die SD-Card ein weg hat? Gestern ist mir das Problem noch nicht aufgefallen.
Dank müsste ja hier auch der Fehler kommen, oder nicht?
pi@FHEM-Server4:~ $ sudo apt-get update
Holen:1 http://archive.raspberrypi.org/debian stretch InRelease [25,4 kB]
OK:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Es wurden 25,4 kB in 0 s geholt (29,8 kB/s).
Paketlisten werden gelesen... Fertig
pi@FHEM-Server4:~ $ sudo apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
pi@FHEM-Server4:~ $
Weil sich SD-Kartenfehler oft durch "solche plötzlichen komischen Dinge" äußern (können)...
Und wenn PI und SD ist das die erste, naheliegenste Vermutung (bei "Sowas") die man haben kann/muss ;)
Gruß, Joachim
Ok, danke. Dann spiele ich das gestrige Voll-Backup mal auf eine neue SD Card.
Ändert aber grundsätzlich nichts zum Thema, weshalb speedtest in Fhem nicht läuft. Woher bekommt man nun die geänderte 32_speedtest.pm ?
Denke doch, das der Entwickler des Moduls etwas geändert hat.
Naja, wenn es wirklich die SD ist, dann sind die Fehler hoffentlich nicht schon in deinem Voll-Backup von gestern drin...
Bzgl. des speedtest-Moduls, also ich habe nichts notiert, dass ich das "selbst besorgt" hätte.
Ich glaube es ist/sollte im ganz normalen Update drin sein.
Wenn du das Attribut ookla hast, dann muss es doch passen!?
EDIT: https://forum.fhem.de/index.php/topic,114118.msg1088346.html#msg1088346
Gruß, Joachim
SD Card (ich hoffe es mal nicht), sonst ein noch älteres Backup nehmen. So viele Änderungen hatte ich nicht in letzter Zeit :o
ookla Attr habe ich , ja.
Fehler bleibt weiterhin:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
2020.11.13 11:50:49 1: PERL WARNING: Use of uninitialized value $a[1] in pattern match (m//) at ./FHEM/32_speedtest.pm line 181.
2020.11.13 11:50:49 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
2020.11.13 11:50:49 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 213.
2020.11.13 11:50:49 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
Also bei mir läuft es...
Was ich gemacht habe (aber wohl unnötig ist, macht das Modul wohl auch): ich habe den ookla speedtest 1x als User fhem ausgeführt und die "Bedingungen akzeptiert"...
Hast du folgende Datei:
/opt/fhem/.config/ookla/speedtest-cli.json
Ansonsten muss halt Andre mal schauen, wenn dein System sonst wieder ok ist...
Gruß, Joachim
ja Ersttest hatte ich auch gemacht , allerdings als user pi.
Siehe Post (https://forum.fhem.de/index.php/topic,115313.msg1100805.html#msg1100805).
So nun nochmal mit User fhem:
pi@FHEM-Server4:~ $ sudo -u fhem /bin/bash
fhem@FHEM-Server4:/home/pi$
fhem@FHEM-Server4:/home/pi$
fhem@FHEM-Server4:/home/pi$
fhem@FHEM-Server4:/home/pi$ speedtest
==============================================================================
You may only use this Speedtest software and information generated
from it for personal, non-commercial use, through a command line
interface on a personal computer. Your use of this software is subject
to the End User License Agreement, Terms of Use and Privacy Policy at
these URLs:
https://www.speedtest.net/about/eula
https://www.speedtest.net/about/terms
https://www.speedtest.net/about/privacy
==============================================================================
Do you accept the license? [type YES to accept]: YES
License acceptance recorded. Continuing.
==============================================================================
Ookla collects certain data through Speedtest that may be considered
personally identifiable, such as your IP address, unique device
identifiers or location. Ookla believes it has a legitimate interest
to share this data with internet providers, hardware manufacturers and
industry regulators to help them understand and create a better and
faster internet. For further information including how the data may be
shared, where the data may be transferred and Ookla's contact details,
please see our Privacy Policy at:
http://www.speedtest.net/privacy
==============================================================================
Do you accept the license? [type YES to accept]: YES
License acceptance recorded. Continuing.
Speedtest by Ookla
Server: IBH IT-Service GmbH - Dresden (id = 2495)
ISP: Deutsche Telekom AG
Latency: 6.67 ms (0.34 ms jitter)
Download: 170.89 Mbps (data used: 85.5 MB)
Upload: 41.65 Mbps (data used: 18.8 MB)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/7ae70c49-287b-4977-9f6b-0e7a828ad8c5
fhem@FHEM-Server4:/home/pi$
Jetzt habe ich auch den .config/ookla Ordner.
Dann copiere doch mal die Datei "speedtest-cli.json" vom User pi zu fhem:
Wenn Du root bist:
mkdir -p /opt/fhem/.config/ookla/
cp /home/pi/.config/ookla/speedtest-cli.json /opt/fhem/.config/ookla/
chown -R fhem: /opt/fhem
Wieso sollte ich das tun?
Ist doch denke ich so, wie es sein sollte oder? Habe den Erst "speedtest" Aufruf doch eben nochmal mit User: fhem gemacht.
Was mich ja stört ist, das 32_speedtest.pm nicht per update all kommt und weiterhin der Fehler im Log ist. Solange ich nicht die neue .pm habe wird das nix werden. Kann mir nicht einer diese Datei hochladen?
2020.11.13 14:53:03 1: PERL WARNING: Use of uninitialized value $a[1] in pattern match (m//) at ./FHEM/32_speedtest.pm line 181.
2020.11.13 14:53:03 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
2020.11.13 14:53:03 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 213.
2020.11.13 14:53:03 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
... um das doch so unwichtige Modul mal abzuschließen, folgendes:
Hatte mir mal den Spass gemacht in diesem Zuge mit einer Backup SD-Card von Stretch auf Buster upzugraden und siehe da, der Fehler taucht nun nicht mehr auf und speedtest wird aus den deb Paket von
deb https://ookla.bintray.com/debian buster main
sauber installiert. (Also nix da, mit defekter SD-Card / eher das Problem von stretch) Danach mit User pi und auch fhem den zertifizierten Testlauf mit zweimal YES vollzogen.
/opt/fhem/.config/ookla/speedtst-cli.json
gibt es nun.
Nur wo ist die speedtest in /usr/local/bin ??
In Andre's Modul sehe ich das in Zeile 213
if( $a[1] eq "Invalid server ID" ) {
readingsSingleUpdate($hash,"state", "failed", 1);
return;
}
genau das in meinem Log immer noch angemeckert wird.
Ebenso in Zeile 181 das die ookla.json bei aktivierte attr 1 gefordert wird. Alles ist doch m.E. vorhanden?! Alles sollte doch keine Hexerei sein.
if( $a[1] =~ m/^\{.*\}$/ ) {
if( !$speedtest_hasJSON ) {
Log3 $name, 1, "json needed for ookla speedtest";
return;
}
Für mich scheinbar zu hoch, nur ärgerlich, dass alles vor 5 Tagen noch funktionierte.
Nun doktore ich hier rum, weil der "state" permanent failed anzeigt und das Modul nicht mehr funktioniert.
Weiß nicht was bei anderen funktioniert ...
Schleierhaft nur, wo die korrekte Install mit:
sudo apt-get install speedtest
was auch immer, wohin kopiert. In usr/local/bin ist nix und mit find, wird nur das geliefert : (das sehe ich mit WinSCP auch)
pi@Pi3FHEM-Server4:~ $ find . |grep speedtest
./.config/ookla/speedtest-cli.json
Weitere Errors im Log:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
2020.11.13 19:21:30 1: PERL WARNING: Use of uninitialized value $a[1] in pattern match (m//) at ./FHEM/32_speedtest.pm line 181.
2020.11.13 19:21:30 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
2020.11.13 19:21:30 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 213.
2020.11.13 19:21:30 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
Sagt mir mal einer, was das nun genau bedeutet??
Danke
P.S. Wenigstens habe ich nun ein funktionierendes FHEM mit Buster ;-)
Ich hake das nun ab, mit dem Ergebnis ein wenig Zeit vergeudet zu haben ...
(Weiß ja was meine DSL Leitung bringt / wird es eben dann nicht mehr auf TabletUI angezeigt)
Was sagt das Kommando whereis (auf der Konsole)?
also hier z.B.:whereis speedtest
Unter der Voraussetzung, das auf der Konsole das Kommando speedtest lautet, sonst bitte anpassen
die speedtest 1836kB habe ich aus dem Paket extrahiert und manuell nach /usr/local/bin kopiert, daher listet dein Befehl das hier:
speedtest: /usr/bin/speedtest /usr/local/bin/speedtest /usr/share/man/man5/speedtest.5
Funktioniert aber trotzdem nicht ... (Besitzer/Gruppe der speedtest ist root/staff) Liegt hier das Problem?
Zitat... habe ich aus dem Paket extrahiert ...
Auch die Rechte, Stichwort ausführbar, angepasst?
Mal ausprobiert: "/usr/bin/speedtest"
Und wenn das funktioniert, wäre ein symlink besser gewesen ..
Das ist nur der Perl-Teil, der wohl aus
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not validresultiert. Würde als Quelle mal das speedtest binary dafür in den Raum stellen. Der Perl-Teil kommt, weil die Fehlerbehandlung / die Sanity-Checks des Moduls ... ungut riechen.
Die Frage bleibt: Warum schmeißt das Binary den Fehler?
ZitatDank müsste ja hier auch der Fehler kommen, oder nicht?
Nein, hier wird über http geholt, nicht über https.
Schauen wir doch mal:
$ apt-rdepends speedtest
Reading package lists... Done
Building dependency tree
Reading state information... Done
speedtest
Depends: ca-certificates
ca-certificates
Depends: debconf (>= 0.5)
Depends: debconf-2.0
Depends: openssl (>= 1.1.1)
debconf
PreDepends: perl-base (>= 5.20.1-3~)
perl-base
PreDepends: dpkg (>= 1.17.17)
PreDepends: libc6 (>= 2.28)
dpkg
Depends: tar (>= 1.28-1)
PreDepends: libbz2-1.0
PreDepends: libc6 (>= 2.15)
PreDepends: liblzma5 (>= 5.2.2)
PreDepends: libselinux1 (>= 2.3)
PreDepends: zlib1g (>= 1:1.1.4)
tar
PreDepends: libacl1 (>= 2.2.23)
PreDepends: libc6 (>= 2.17)
PreDepends: libselinux1 (>= 1.32)
libacl1
Depends: libattr1 (>= 1:2.4.46-8)
Depends: libc6 (>= 2.14)
libattr1
Depends: libc6 (>= 2.4)
libc6
Depends: libgcc1
libgcc1
Depends: gcc-8-base (= 8.3.0-6)
Depends: libc6 (>= 2.14)
gcc-8-base
libselinux1
Depends: libc6 (>= 2.14)
Depends: libpcre3
libpcre3
Depends: libc6 (>= 2.14)
libbz2-1.0
Depends: libc6 (>= 2.4)
liblzma5
Depends: libc6 (>= 2.17)
zlib1g
Depends: libc6 (>= 2.14)
debconf-2.0
openssl
Depends: libc6 (>= 2.15)
Depends: libssl1.1 (>= 1.1.1)
libssl1.1
Depends: debconf (>= 0.5)
Depends: debconf-2.0
Depends: libc6 (>= 2.25)
Möglicherweise haben speedtest und apt das gleiche Problem: Eine defekte SSL-Komponente. Das ist aber nur eine wilde Vermutung. Würde das System komplett frisch aufsetzen und dann mal nur die FHEM-Konfiguration testweise migrieren.
Lese gerade, dass du das inzwischen getan hast. Liefert denn apt auch noch einen Fehler, wenn du etwas über https installieren willst?
Ja wurde gemacht:
pi@Pi3FHEM-Server4:~ $ sudo chmod +x /usr/local/bin/speedtest
Zitat von: Christoph Morrison
Würde das System komplett frisch aufsetzen und dann mal nur die FHEM-Konfiguration testweise migrieren.
Lese gerade, dass du das inzwischen getan hast. Liefert denn apt auch noch einen Fehler, wenn du etwas über https installieren willst?
Ok, war eine Überschneidung der Posts. Wollte Dich schon fragen ob ich komplett Buster neu installieren soll, nur wegen so einem speedtest . Hoppla ;-)
Also schrieb ich doch oben, das mit dem Upgrade auf Buster vom Stretch meines Backups
nicht mehr der apt Fehler kommt. Wäre mal interessant, ob ein Stretch User ähnliche/genau das Problem bei der Binary Cli install hat/hatte. Weil meine Sandisk Ultra SD ist ein Jahr alt, da zu "vermuten" deine Card ist defekt konnte ich nicht glauben ...
Edit: Screen (die aktuelle binary speedtest ist vorhanden in /user/local/bin), warum gehst dann nicht? Ebenso die verifizierte .json.
Aber ich gebe heute mal auf, hab noch andere (non FHEM) Kodi Baustellen ;-) Vielen Dank für eure Unterstützung, aber ganz so wichtig ist das Modul nun auch wieder nicht. Vielleicht bietet mir Andre noch ein Denkanstoß, immerhin ist das Modul von ihm.
Zitat von: topa_LE am 13 November 2020, 20:19:48
Ok, war eine Überschneidung der Posts. Wollte Dich schon fragen ob ich komplett Buster neu installieren soll, nur wegen so einem speedtest . Hoppla ;-)
Die Antworte wäre ja gewesen ;-)
Zitat von: topa_LE am 13 November 2020, 20:19:48
Also schrieb ich doch oben, das mit dem Upgrade auf Buster vom Stretch meines Backups nicht mehr der apt Fehler kommt. Wäre mal interessant, ob ein Stretch User ähnliche/genau das Problem bei der Binary Cli install hat/hatte.
Hab ich jetzt gerade auch gelesen ;-)
Zitat von: topa_LE am 13 November 2020, 20:19:48
Weil meine Sandisk Ultra SD ist ein Jahr alt, da zu "vermuten" deine Card ist defekt konnte ich nicht glauben ...
Das muss nix heißen. Ich hatte eine SD-Karte vier Jahre im Betrieb und hab die dann manuell gekillt (durchgebrochen, dicke Finger). Eine andere hat kein Jahr gehalten. Es gibt viele Faktoren.
Zitat von: topa_LE am 13 November 2020, 20:19:48
die speedtest 1836kB habe ich aus dem Paket extrahiert und manuell nach /usr/local/bin kopiert
Warum? Du kannst doch im Modul den Pfad zum Modul im Attribut
path angeben (so bei mir, Buster mit ookla Speedtest):
Internals:
.FhemMetaInternals 1
CFGFN ./cfg.d/general/utilities/interwebs.cfg
FUUID 5fa98457-f33f-0f53-11c2-7d794f3392483fb8
FVERSION 32_speedtest.pm:0.229190/2020-10-05
INTERVAL 3600
NAME general.utilities.interwebs.speedtest
NR 4553
STATE Upload 42.10 MByte/s., Download 21.10 MByte/s. Ping 10.79 ms
TYPE speedtest
.attraggr:
.attrminint:
Helper:
READINGS:
2020-11-13 19:50:04 download 21.1
2020-11-13 19:50:04 id 17392
2020-11-13 19:50:04 location Dusseldorf
2020-11-13 19:50:04 name myLoc managed IT AG
2020-11-13 19:50:04 packetLoss 0
2020-11-13 19:50:04 ping 10.792
2020-11-13 19:50:04 state ok
2020-11-13 19:50:04 upload 42.1
helper:
Attributes:
alias Ookla Speedtest
group Netzwerk
icon speed-test@black
ookla 1
path /usr/bin
room Allgemein->Netzwerk
stateFormat Upload [$name:upload:d2] MByte/s., Download [$name:download:d2] MByte/s. Ping [$name:ping:d2] ms
Zitat von: Christoph Morrison
Warum? Du kannst doch im Modul den Pfad zum Modul im Attribut path angeben (so bei mir, Buster mit ookla Speedtest):
Tja, wenn ich wüsste wo die installiere binary speedtest installiert wurde, hätte ich das gemacht.
Die aktuell einzige existierende speedtest habe ich manuell kopiert.
Besten Dank für dein Denkanstoss! ;-) Setze den Path mal nach usr/bin ...
Danke hoffe ich es klappt! ;-)
Ich las es sein, klappt nicht.
Danke dir trotzdem.
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
2020.11.13 20:39:58 1: PERL WARNING: Use of uninitialized value $a[1] in pattern match (m//) at ./FHEM/32_speedtest.pm line 181.
2020.11.13 20:39:58 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
2020.11.13 20:39:58 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 213.
2020.11.13 20:39:58 3: eval: {speedtest_SpeedtestDone('WEB_Speedtest|')}
Ich kenne mich ja selbst ;-)
Hat mir echt keine Ruhe gelassen.
Nach nochmals Recherche ist es tatsächlich so, das man in die /etc/init.d/fhem folgendes setzen muss:
Zeile 15/16 ergänzend: export HOME=/opt/fhem
### END INIT INFO
sleep 10
set -e
cd /opt/fhem
export HOME=/opt/fhem
port=7072
Ist nur echt etwas quicky! Wer soll das wissen, der sich nicht so richtig auskennt. ... und das bei so einem doch so unwichtigen Modul!
Lüppt jetzt wieder wie es soll.
Da sollte Andre oder ein anderer mal es im Wiki ergänzen ...
Schönen Abend noch.
DONE :-)
Naja, initd ist halt "Historisch" Stretch bzw. eigentlich sogar noch Jessie (und früher)...
Auf einem "nativen" Buster wird fhem durch systemd gestartet...
Vielleicht ist das somit auch nur bei dir das Problem: unter Stretch das Problem mit dem Installieren von speedtest und nach dem Upgrade zu Buster dann das Problem mit Home... ;)
Gruß, Joachim
P.S.: Aus diesem und anderen Gründen halte ich eben nichts von Upgrades...
...ich installiere sauber/neu...
Gebe ich dir voll Recht, nur die Zeit habe ich nicht.
Habe bisher von Jessie -> Stretch -> und Dralala upgegraded. Irgendwann muss ich mal völlig neu aufsetzen. aber jede Menge Arbeit.
Aktuell läuft meine FHEM (4 Jahre) sehr gut mit alle erdenklichen Defines. Aber richtig, mal NEU machen ist nicht verkehrt ... nur jetzt noch nicht ;-)
Besten Dank für Eure Unterstützung.
Schönes WE.
Konnte dank dem Speedtest Vodafone Kabel Deutschland beweisen, dass die Leitung echt mies ist.
Seit Freitag bei der Telekom mit DSL und happy. Telekom Leitung ist zwar nicht ganz so schnell, aber stabil und besserer Ping.
Die Graphen sprechen für sich :-)
Hallo Slor
Es freut mich sehr, dass du eine Lösung gefunden hast! Wenn etwas nicht so funktioniert, wie man es gerne hätte, dann kann es mit der Zeit echt mühsam werden. Hoffentlich funktioniert nun alles einwandfrei. Ich drücke dir die Daumen ;D.
Moin,
vielleicht liest es ja noch jemand hier.
Ich scheute mich, etwas Neues aufzumachen.
Habe seit heute dieses Problem und weiß nicht, wo ich suchen soll:
pi@raspb:~ $ sudo speedtest-cli --list | grep Germany
Cannot retrieve speedtest configuration
ERROR: HTTP Error 403: Forbidden
Speedtest terminiert mit failed.
Zitat von: Ralph am 07 August 2022, 21:42:21
Moin,
vielleicht liest es ja noch jemand hier.
Ich scheute mich, etwas Neues aufzumachen.
Habe seit heute dieses Problem und weiß nicht, wo ich suchen soll:
pi@raspb:~ $ sudo speedtest-cli --list | grep Germany
Cannot retrieve speedtest configuration
ERROR: HTTP Error 403: Forbidden
Speedtest terminiert mit failed.
Bist wohl nicht alleine: https://forum.fhem.de/index.php/topic,114118.msg1230361.html#msg1230361
Ich nutze allerdings ookla...
Gruß, Joachim
Danke Dir für die Antwort. Nun gerade gehts wieder.
Aber auch Danke für den Wink mit ookla. Ich las schon mal was, aber es war mir wieder entfleucht.
Hallo zusammen,
da ich gesehen hab, dass auf diesen Beitrag (https://forum.fhem.de/index.php/topic,114118.msg1230357.html#msg1230357) Bezug genommen wurde, wollte ich erwähnen, dass ich die ookla-Variante nicht zum Laufen gebracht habe. Beta-User versucht mir gerade im obigen Thread zu helfen.
Viele Grüße Gisbert
Moin Gisbert,
habe ookla mal installiert, läuft auf dem Raspi gut, mit FHEM Speedtest aber nicht, siehe Dein Link.
Hallo zusammen,
ich bin den Diskussions-Thread durchgegangen, bin mir aber nicht ganz sicher, ob das abschließend gelöst wurde. Ich habe den Stacktrace an und bekomme folgende Einträge regelmäßig. Ich verwende (bisher) nicht Ookla.
2022.09.12 07:31:10.328 1: main::CallFn called by fhem.pl (782)
2022.09.12 07:31:10.328 1: main::telnet_Read called by fhem.pl (3961)
2022.09.12 07:31:10.328 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2022.09.12 07:31:10.328 1: main::AnalyzeCommand called by fhem.pl (1125)
2022.09.12 07:31:10.328 1: main::AnalyzePerlCommand called by fhem.pl (1198)
2022.09.12 07:31:10.328 1: (eval) called by fhem.pl (1169)
2022.09.12 07:31:10.328 1: main::speedtest_SpeedtestDone called by (eval 11128075) (1)
2022.09.12 07:31:10.328 1: main::__ANON__ called by ./FHEM/32_speedtest.pm (214)
2022.09.12 07:31:10.328 1: stacktrace:
2022.09.12 07:31:10.328 1: eval: {speedtest_SpeedtestDone('hlathome_speedtest|||')}
2022.09.12 07:31:10.328 1: PERL WARNING: Use of uninitialized value $a[1] in string eq at ./FHEM/32_speedtest.pm line 214.
2022.09.12 07:31:10.328 1: main::CallFn called by fhem.pl (782)
2022.09.12 07:31:10.328 1: main::telnet_Read called by fhem.pl (3961)
2022.09.12 07:31:10.328 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2022.09.12 07:31:10.328 1: main::AnalyzeCommand called by fhem.pl (1125)
2022.09.12 07:31:10.328 1: main::AnalyzePerlCommand called by fhem.pl (1198)
2022.09.12 07:31:10.328 1: (eval) called by fhem.pl (1169)
2022.09.12 07:31:10.328 1: main::speedtest_SpeedtestDone called by (eval 11128075) (1)
2022.09.12 07:31:10.328 1: main::__ANON__ called by ./FHEM/32_speedtest.pm (182)
2022.09.12 07:31:10.328 1: stacktrace:
2022.09.12 07:31:10.328 1: eval: {speedtest_SpeedtestDone('hlathome_speedtest|||')}
Der Speedtest klappt manchmal, manchmal nicht
Internals:
DEF 7200
FUUID 5c8c367f-f33f-0759-bf63-3410b92b2fc2de04
FVERSION 32_speedtest.pm:0.238670/2021-03-01
INTERVAL 7200
LOCAL 0
NAME hlathome_speedtest
NR 76
STATE ok
TYPE speedtest
eventCount 88
Helper:
DBLOG:
download:
logdb:
TIME 1662970077.42792
VALUE 265.93
ping:
logdb:
TIME 1662970077.42792
VALUE 22.757
state:
logdb:
TIME 1662970077.42792
VALUE ok
upload:
logdb:
TIME 1662970077.42792
VALUE 41.09
READINGS:
2022-09-12 10:07:57 download 265.93
2022-02-20 07:21:09 id 40094
2022-02-20 07:21:09 location Frankfurt
2022-02-20 07:21:09 name PVDataNet
2022-02-20 05:21:09 packetLoss 0
2022-09-12 10:07:57 ping 22.757
2022-09-12 10:07:57 state ok
2022-09-12 10:07:57 upload 41.09
helper:
Attributes:
DbLogInclude .*
alias Speedtest Client
comment Alle: speedtest-cli --list | grep Germany
group Communication
path /usr/bin
room Server
Hallo,
Ich hatte auch ständig 403er Fehlermeldung. Abhilfe:
Wenn ich speedtest-cli mit "--secure" aufrufe (bzw die Option in der 32_speedtest.pm ergänze), dann klappts zuverlässig. Habe ich auch gerade hier gepostet:
https://forum.fhem.de/index.php/topic,13419.msg1236431.html#msg1236431
Sorry falls der Post woanders hingehört...
Hallo eddy242!
Haben Sie es bereits mit Ookla versucht? Auch ich erhalte regelmäßig ähnliche Einträge. Mit freundlichen Grüßen!
Hallo,
ich hatte auch diese Probleme mit 403. Ich habe irgendwo gefunden, dass speedtest-cli mit der option --secure aufgerufen werden sollte. Vielleicht stellen die nach und nach die speedtest-Server auf HTTPS um.
Ich habe in der 32_speedtest.pm die Zeile 144 geändert auf:
$cmd .= "/speedtest-cli --simple --secure";
Damit läufts wieder. Vielleicht dann das jemand einpflegen, so dass es mit dem nächsten Update automatisch gefixt wird?
lg
https://forum.fhem.de/index.php/topic,13419.msg1239897.html#msg1239897 (https://forum.fhem.de/index.php/topic,13419.msg1239897.html#msg1239897)