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.
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.
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 :-(
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.
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]
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.
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;
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!