Probleme beim Neustart der Bienenwaage im Mai

7 tage später: ich versuche gerade jetzt auch die waage wieder in betrieb zu nehmen.

die hardware scheints soweit zu machen: ich kriege messwerte und sie kommen auch auf sd wie gehabt (die wägezellen sind nicht angeschlossen, daher kommen da negativwerte).
es tut auch so als ob es an hiveeyes sendet.
allerdings kommen auf dem hiveeyes-panel keine datenpunkte an.

hat sich in der datenaquise seit märz 2018 was geändert?
oder liegt das etwa an den negativwerten fürs gewicht??

vielleicht kann @Andreas mal gucken, ob was ankommt auf dem server?
oder hat sich was geändert und mein datensendemechanismus ist nicht mehr aktuell?

ich hab in der anleitung nach gesehen, aber auf anhieb nichts gefunden.

soweit, alles gute für die nacht,
markus

1 Like

Hi @mois,

schön dass Du wieder mit Bienen und Telemetrie am Start bist.

Mittlerweile kannst Du das selbst - entweder über https://swarm.hiveeyes.org/transmissions oder per mosquitto_sub -h swarm.hiveeyes.org -p 1883 -t '#' -v.

Ich kann leider keinen Dateneingang von 27041c2a-8afd-... entdecken. Allerdings müsste es dazu auch erst auf dem MQTT Bus landen – und Du sendest per HTTP-Weiterleitung, richtig?

Hm, schickst Du Datenpakete im CSV-Format? Falls ja, müssen wir vielleicht das entsprechende Feldnamen-Mapping neu setzen.

Viele Grüße,
Andreas.

Auch im HTTP Logfile per

root@elbanco:~# tail -F /var/log/nginx/swarm.hiveeyes.org-*.log

sehe ich leider keinen Dateneingang von Dir, während von anderswo durchaus etwas per HTTP reinkommt:

52.x.x.x - - [02/Jun/2019:23:40:41 +0200] "POST /api/hiveeyes/testdrive/redacted/redacted/data HTTP/1.1" 200 93 "-" "http-ttn/2.6.0"
87.x.x.x - - [02/Jun/2019:23:40:47 +0200] "POST /api/hiveeyes/open-hive-test-statista/redacted/redacted/data HTTP/1.1" 200 93 "-" "-"

dunkel dämmert mir was: ich glaube ich hab tatsächlich datenreihen mit messfehlern (also z.b. negatives gewicht) irgendwo in meinen sketches rauszensiert…
das muss ich mir nochmal vergegenwärtigen und durchgehen…
kurze zeit später: ja das wars. hab jetzt erstmal die beiden variablen für die waagenwerte mit fixwerten ersetzt. jetzt kommen auf meinem alten selbstgebastelten graph die datenpunkte an :-) aber bei hiveeyes immer noch nicht :-(

Denke aber auch an die Weiterleitung per PHP, die auch noch auf dem Weg zum Ziel liegt. Im Repository findet sich z.B. keine hiveeyes.php, die jedoch bei beescale/add_line2.php at master · bee-mois/beescale · GitHub benötigt wird.

Wenn dort irgendwo etwas schiefgeht, dann bekommst Du so ohne weiteres vermutlich keinerlei Fehlermeldungen. Auch dort nach der Ursache zu suchen, ist bestimmt nicht verkehrt.

doch, die liegt bei mir auf dem server an der richtigen stelle. mit einem “zuletzt geändert”-stamp vom 13.3.2017.
php-version bei mir: [3.6.19: falsch recherchierte php-version berichtigt]7.0.33-1~dotdeb+8.1

Die ist um einiges neuer als beim letzten Mal, daran kann es durchaus liegen.

Hast Du Einblick in die Logfiles?

Die bestmöglichste Vorbereitung und Sicherstellung der Funktionalität kannst Du erreichen, in dem Du a) erstmal absichtlich einen Syntaxfehler im PHP-Script produzierst und nachsiehst, ob Du diesen in irgendeinem Logfile entdecken kannst. b) Dann nochmal ohne diesen bewusst herbeigeführten Fehler aufrufen, dann sollte man sehen, welche Fehler durch die Webanwendung selbst ausgelöst werden.

das muss ich bei in-berlin.de nachhaken. ich finde da zwar einen log-ordner, an den ich rankomme, aber keine für die aktuelle php-version.

dazu brauchts ja auch noch http-terkin.php und da steht ausdrücklich drin “Kotori telemetry client for PHP5”. ist das für meine php-version (7.0) getestet?

Richtig. Da bin ich froh, dass es wenigstens so drinsteht ;].

Definitiv nicht – also ich zumindest nicht. @clemens sprach neulich ebenfalls von einem anstehenden Serverupgrade. Aber ich vermute, Du bist hier derzeit Premierengast.

ok, dann sehn wir mal, was der in-berlin-support sagt.
ich hab ihnen geschrieben:

hallo bester in-berlin-support,

ich versuche einen fehler zu finden in der ausführung von
/home/www/wbk/euse.de/honig/beescale/add_line2.php
bzw. den dort benötigten
/home/www/wbk/euse.de/honig/beescale/hiveeyes.php und
/home/www/wbk/euse.de/honig/beescale/http-terkin.php
ein kompletter aufruf lautet z.b.:
http://www.euse.de/honig/beescale/add_line2.php?.

gibts da für mich zugängliche log-files?
in /home/log/wbk finde ich nichts passendes.
oder übersehe ich da was?

kann es sein, dass http-terkin.php (“Kotori telemetry client for PHP5”)
fehler verursacht, weil es nicht mit meiner php version (7.3)
zusammenspielt?

hintergrund des ganzen ist debugging bei der wieder-inbetriebnahme
meiner bienenwaagen, nachdem ich jetzt wieder bienen habe. [1]

vg,
markus

[1] Neustart der Bienenwaage im Mai

da rechne ich heute nicht mehr mit antwort. und ich muss sowieso jetzt ins bett.
also bis bald,
markus

jetzt kommen die daten wieder durch, wie das Grafana Dashboard zeigt.

ich zitiere den entscheidenden teil der antwort von christian/in-berlin.de:

Am 03.06.19 um 21:35 schrieb Christian Seitz:

Wir haben allow_url_fopen aus bekannten
Sicherheitsgruenden per Default aus.

einfacher für mich als per curl (weil ich dann nichts umschreiben muss),
wäre es, wenn ihr mir für den einen server, unseren telemetrieserver
(https://swarm.hiveeyes.org/api/), eine erlaubnis schalten würdet.

Software die allow_url_fopen zwingend benoetigt kann ich mir heute eigentlich
nicht mehr vorstellen.

hintergrund: bis märz 2018 hat es genau so funktioniert, allerdings mit
der alten php-version. dann hab ich die bienenwaage abgestellt, weil
alle bienen tot waren. irgendwann später 2018 habt ihr mir danna auf
meine bitte hin wegen wordpress und/oder piwik/matomo auf die aktuellere
php-version umgestellt. leider finde ich den mailverkehr nicht mehr, um
genau zu rekonstruieren, wie wir das damals diskutiert hatten mit der
erlaubnis für diese url-abfrage durch php. oder hattet ihr früher diese
standardeinstellung so nicht? ich kann mich nicht erinnern.

allow_url_fopen ist seit 2006 deaktiviert, siehe auch unser Newsartikel von
damals: IN-Berlin - erweitere Sicherheit auf dem User-Webserver

Auch bei vielen anderen Providern ist da deaktiviert, da es ueber
Sicherheitsluecken ausgenutzt sehr oft zum Nachladen von Schadcode genutzt wird.

Meine PHP-Zeit ist lange her, aber mit Hilfe von Google habe ich gerade mal
terkin-hhtp.php geaendert. Die alte Version liegt als terkin-hhtp.php.orig
daneben. Kannst Du bitte mal pruefen, ob das mit dem Curl-Aufruf funktioniert
und sinnvolle Daten auf der anderen Seite ankommen?

die änderung in der terkin-http.php betreffen die funktion transmit:

    function transmit($data) {
           /*
            * Submit telemetry data using HTTP POST request
            * Serialization: x-www-form-urlencoded
            */

            $payload = http_build_query($data);

	    $curl = curl_init ();
	    curl_setopt ($curl, CURLOPT_HTTPHEADER, array (
		    'Content-type: application/x-www-form-urlencoded'
	    ));
	    curl_setopt ($curl, CURLOPT_RETURNTRANSFER, 1);
	    curl_setopt ($curl, CURLOPT_POST, 1);
	    curl_setopt ($curl, CURLOPT_POSTFIELDS, $payload);
	    curl_setopt ($curl, CURLOPT_URL, $this->uri);
            $result = curl_exec ($curl);
            if ($result === FALSE) {
                error_log("Could not submit telemetry data to '$uri', payload='$payload'");
            }
	    curl_close ($curl);

            return $result;

hier nochmal die links zur neuen terkin-http.php (mit curl) und zur alten terkin-http.php (ohne curl).

2 Likes

Hi @mois,

fein, dass die Telemetrie wieder läuft und vielen Dank fürs Teilen der Hintergründe, die bei Dir zum Ausfall der Telemetrie geführt haben. Danke auch an Christian Seitz bei IN-Berlin fürs Debugging und die ausführliche Erklärung.

Für file_get_contents() ist allow_url_fopen wohl scheinbar obligatorisch. Bummer - we missed that important detail!

Eine auf libcurl basierende Variante hatten wir tatsächlich bereits für PHP4 bereitgelegt, siehe terkin-http.php4 (via: Data acquisition with PHP — Hiveeyes system documentation 0.9.0 documentation).

Mit kleinen Anpassungen müsste diese also auch fast 1:1 für PHP 7.x taugen.

Danke dafür! Die Terkin-Clients für die verschiedenen PHP-Versionen liegen bei kotori/clients/runtime/php at 0.22.7 · daq-tools/kotori · GitHub.

Ihm wird das sicherlich ebenfalls weiterhelfen, was Du herausgefunden hast. Danke nochmals!

Viele Grüße,
Andreas.


P.S.: Jetzt könnte @wtf hier ran… ;].

Die angepasste Version liegt nun unter kotori/terkin-http.php at master · daq-tools/kotori · GitHub. Wenn Du es mit dieser noch einmal testen könntest, bin ich Dir sehr zu Dank verpflichtet.

klappt: alle werte nach 23 uhr kommen durch deine version.

1 Like

Exzellent. Vielen Dank nochmals an Dich und Christian an dieser Stelle! Vorauseilend auch schon im Namen von @clemens ;].

1 Like