Daten Puffern und als Bulk an Beep/BOB schicken

snooz · June 8, 2021, 6:39pm

Ich hab gesehen, dass das “originale” beep den key ‘time’ akzeptiert und damit auch historische Daten eingebettet werden können.
Es gibt leider bei beep eine Restriktion von von Calls per Minute oder so.

Was haltet ihr davon, den time key auch in BOB einzubauen?
@Diren

Dann würde ich die FiPy programmierung so erweitern, dass bei WLAN Verlust daten gepuffert und bei Wiederherstellung an BOB nachgeliefert werden.

snooz · June 8, 2021, 7:11pm

github.com

Hiverize/BEEP/blob/2ff418675c2e77896ba6686101e7595a572bcb55/app/Http/Controllers/Api/SensorController.php#L456




        // take into account offset and multi
        $weight_kg = $this->calculateWeightKg($sensor, $data_array);
        $data_array['weight_kg'] = $weight_kg;


        // check if we need to compensate weight for temp
        $data_array = $this->add_weight_kg_corrected_with_temperature($sensor, $data_array);
    }
    
    //die(print_r($sensor_key));
    $stored = $this->storeInfluxData($data_array, $sensor_key, time());
    if($stored) 
    {
        return Response::json("saved", 201);
    } 
    else
    {
        Storage::disk('local')->put('sensors/sensor_write_error.log', json_encode($data_array));
        return Response::json('sensor-write-error', 500);
    }
}

Hier müssten wir anstatt time() einen key ‘time’ auslesen, falls vorhanden.

Oder noch viel besser, einen Call hinzufügen, der eine Liste von Dictionaries schicken kann.
Dann könnten wir mit einem einzelnen Call alle nicht gesendeten Daten in die DB pumpen.

Damit wären sogar sowas wie offline Messungen möglich.

Beispiel:

FiPy ist darauf programmiert auf den Hotspot den Handys zu verbinden.
Wenn der Imker am Stand ist, macht er mal den hotspot an und der FiPy verbindet sich.
Zack, übermittelt die Messdaten einer Woche und der imker macht den Eintrag ins Log und fährt wieder.

Andreas · June 8, 2021, 7:31pm

Hi René,

Das hört sich für mich wie das Imker als Datenmuli Szenario an, ich glaube @clemens hat es auch bei Solarbetrieb der BOB-Platine, verschiedene Möglichkeiten - #71 by Andreas beschrieben.

Viele Grüße,
Andreas.

clemens · June 8, 2021, 8:20pm

@Diren und auch Michael / @MKO glaube ich haben für ein Projekt in Afrika, das afaik dann durch Corona (noch) nicht umgesetzt wurde, die Bob-Software geforked und eine Version entwickelt, die Daten temporär auf SD speichert und dann im bulk verschickt wenn jemand mit mobiler Datenverbindung in der Nähe der Beute ist. Allerdings schrieb sie direkt in die Datenbank, was nicht so optimal ist.

snooz · June 8, 2021, 8:26pm

@Andreas

Ja so vom Grundsatz her ja.
Aber selbst wenn man das alles baut und so, dann gibt es immer noch das Problem, dass wir dann die gespeicherten Daten nicht an BOB senden können, oder?

Wobei ich hier den Komfort gerne erhalten möchte.
Für das “Datenmuli Szenario” wären ein paar Dinge notwendig:

WLAN immer aus, außer es wird durch Imker*in getriggert.
Zum Trigger verwendet man den P16 taster nur eben nicht als Taster, sondern als Magnetkontakt:
https://www.amazon.de/dp/B085XQGX2L/ref=cm_sw_em_r_mt_dp_ZTK53APQKE6SW4XS1HNX?_encoding=UTF8&psc=1
Dann muss das Gehäuse nicht aufgemacht werden.
P16 hat 2 Modi. kurz=Startet den AP für 5 Minuten. Lange=Startet WLAN und versucht sich mit dem konfigurierten WLAN zu verbinden und alle Daten zu verschicken. (so lange aktiv, wie der Magnet am Magnetschalter hängt ?!)
einen HTTP Call wird benötigt, der eine Liste von data dictionaries akzeptiert, wobei jedes data object einen timestamp haben muss.
Ich denke, dass der Call in Beep recht simple zu implementieren ist.
Oder gibt es sowas schon? Ich hab nix gefunden.

Die Anpassungen an der Software könnte ich machen.
Ich kenne echt mehrere Imker, die Ihre Bienen an einem Ort ohne WLAN haben.

Schrebergarten
Gartenhaus
Flachdach der Firma
Jagdhütte
Hinterm Kuhstall

Und das sind nur die Imker*innen, die ich persönlich kenne und die bei den Sensorbeuten abgelehnt haben, weil kein WLAN.
Aber ein iPhone oder Android hat echt fast jeder. Und an vielen dieser Stellen gibt es selbst in DE sogar Handyempfang.
Und ich würde fast sogar sagen, dass diese Art von Daten über Edge gehen sollten.

MKO · June 9, 2021, 7:48am

Wie @clemens und @Andreas beschrieben haben, haben wir dieses schon bei der Kammerun Firmware umgesetzt und auch sonnst schon oft besprochen. Wie @clemens beschrieben hat, ist es derzeit leider nur direktem Zugriff auf die Datenbank möglich.
Die dazu benötigten Accounts müssen manuell erstellt werden und sie gefährden die Sicherheit und Konsistenz der Datenbank. Wenn ein direktes senden über Beep problemlos möglich wär, hätte Diren es bestimmt dort schon umgesetzt.

Im Git gibt es für die BOB Software auch schon einen entsprechenden Branch.
Eine Diskussion dazu hier unten, wichtig ist vor allem das der Node die Zeit jederzeit relativ genau weiß. Was eine zusätzliche RTC nötig macht.

clemens · June 9, 2021, 8:17am

Ja, da gibt es schon was, zumindest in der API-Dokumentation v0.4, @marten.schoonman hatte die mal über den Slack-Kanal von Beep geteilt: [disclaimer] Ich weiß nicht, welche API-Version BOB gerade unterstützt, also ob das schon drin ist.

Beep-Sensor-data-API-v0.4.pdf (52.7 KB)

D.h. pro Datensatz einen call, keinen multiple ingest mit einem HTTP-Aufruf.

Du meintest oben aber, dass der Server bei einem Massen-ingest irgendwann die Annahme verweigert?

Hast du in der Beep-Server-Software was dazu gefunden oder ist das eine limitation, die vom Server (so was wie ein “DOS-Schutz”) kommt? Das sollten wir theoretisch aber beides ändern können, da wir vollen Zugriff auf die Beep-Software und auch den bee-observer.org-Server haben. Daran sollte es nicht scheitern!

snooz · June 9, 2021, 5:45pm

Ja im aktuellen Source code gibt es “throttle” parameter. Ich vermute, dass das Calls pro minute sind. Andere Calls haven andere als 10,1 parameter.

Beepnl

github.com

beepnl/BEEP/blob/2ebb780f300e8cfd371e3eb2e52d9c7a30fa6fa9/routes/api.php#L24


      
          */
          
          Route::group(['middleware' => \Barryvdh\Cors\HandleCors::class], function()
          {    
          
          	Route::get('/',function(){
          		return redirect('webapp');
          	});
          
          	// save sensor data of multiple sensors
          	Route::post('sensors', 		'Api\MeasurementController@storeMeasurementData')->middleware('throttle:10,1');
          	Route::post('lora_sensors', 'Api\MeasurementController@lora_sensors')->middleware('throttle:100,1');
          
          	// save sensor data of multiple sensors (unsecure)
          	Route::post('unsecure_sensors', 'Api\MeasurementController@storeMeasurementData');
          	
          	// User functions
          	Route::post('register', 	'Api\UserController@register')->middleware('throttle:10,1');
          	Route::post('login', 		'Api\UserController@login')->middleware('throttle:10,1');
          	Route::post('user/reminder','Api\UserController@reminder')->middleware('throttle:10,1');
          	Route::post('user/reset', 	'Api\UserController@reset')->middleware('throttle:10,1');

Hiverize

github.com

Hiverize/BEEP/blob/2ff418675c2e77896ba6686101e7595a572bcb55/routes/api.php#L31


      
          		return redirect('webapp');
          	});
          
          	// User functions
          	Route::post('register', 	'Api\UserController@register');
          	Route::post('login', 		'Api\UserController@login');
          	Route::post('user/reminder','Api\UserController@reminder');
          	Route::post('user/reset', 	'Api\UserController@reset');
          
          	// save sensor data of multiple sensors
          	Route::post('sensors', 		'Api\SensorController@store');
          	Route::post('lora_sensors', 'Api\SensorController@lora_sensors');
          
          	// save sensor data of multiple sensors (unsecure)
          	Route::post('unsecure_sensors', 'Api\SensorController@store');
          
          	Route::group(['middleware'=>'auth:api'], function()
          	{  
          		// Authenticate and provide the token
          		Route::post('authenticate', 		'Api\UserController@authenticate');

In unserer Version von Beep gibt es den timestamp auch nicht als Parameter. Da wird immer time() verwendet.

Fraglich ob sich ein Update lohnt. In einem Fork wäre zwar die Implementierung easy, aber wir würden uns fixes aus dem upstream project (beepnl) verbauen.

snooz · June 9, 2021, 5:53pm

Ja ein RTC wäre notwendig, wenn wir mit Stromausfall rechnen müssten.
Ansonsten könnten wir auch die Startzeit auf die letzte geschriebene Zeit plus PowerCycleDuration setzen. Und beim Auslesen, wird neu synchronisiert.

Dennoch. Für den Fall von unstabilem WLAN würde vermutlich auch der Betrieb ohne RTC reichen.

snooz · June 9, 2021, 6:00pm

Ich hätte jetzt auch anstelle einer RTC einen GPS Empfänger für die Zeit genommen.

GY-GPS6Mv2
So was in der Richtung.

Hier mal was infos dazu.

Den Standort bekommt man kostenfrei dabei

snooz · June 9, 2021, 6:33pm

Wobei eine RTC auch krass billig ist

snooz · June 9, 2021, 6:44pm

Aber all diese RTC und Firmware Fragen sind ja was, was auf der Nutzerseite gelöst werden kann.

Der fehlende Call im BOB ist der “Blocker” würde ich sagen.
Ein POST kann gut und gerne ja mal mehr als eine Sekunde dauern.
Wenn wir jetzt eine halbe Stunde kein WLAN haben, müssten wir 30*12 =360 Calls basetzen. Das dauert echt lange. Und ist krass ineffizient.

Bei beepnl hat ein Entwickler mein Issue sofort geschlossen, ohne mal ins Gespräch zu gehen oder die Anfrage überhaupt verstanden zu haben.
Ich schau jetzt mal , ob die im Slack gesprächsbereiter sind.

snooz · June 9, 2021, 6:46pm

Gibt es Erkenntnisse darüber. Woran die “Lücken” in den Sensordaten liegen?

Bei letzten Datentreffen von BOB wurde über fehlende Sensordaten gesprochen.

MKO · June 10, 2021, 7:09am

Die Zeit von einem GPS Empfänger zu bekommen klingt äußerst interessant.
Gerade beim Wanderimkern oder bei Diebstahl könnte das hilfreich sein.
Hast Du schon etwas Erfahrung damit?
Soweit ich weiß kann es mehrere Minuten dauern, bis die Position bestimmt Die Uhrzeit ist hoffe ich etwas schneller verfügbar.
Bei Batterie oder Solarbetrieb müsste man dann sicher Ereignisse festlegen, wann er Uhr und GPS abfragt und überträgt.
Wenn GPS Daten zu swarm.Hiveeyes.org gesendet werden müssen auch zumindest die letzten stellen der Koordinaten verschlüsselt werden.

Diren · June 10, 2021, 8:55am

Hi, hab gerade nicht so viel Zeit alles ganz genau zu lesen und zu antworten, aber ich finde das natürlich immer noch eine sinnvolle sache. Bei der Implementierung für Kamerun mit dem Versenden direkt an die DB war der letzte Stand, dass es an sich funktioniert hat, aber weil alles noch als json oder so versendet wurde, hat das sehr lange gedauert (~15 Minuten für ein Tag Daten). Eine Anpassung der Beep App wäre generell möglich. Viele Grüße, Diren

clemens · June 10, 2021, 3:03pm

Rene / @snooz habe bei deinem GitHub issue bei beep.auch kommentiert.

Was mir gerade dabei noch aufgefallen ist: Den throttle-Parameter gibt es nur oben, unten bei unsecure nicht, könnte es damit schneller gehen?

github.com

beepnl/BEEP/blob/2ebb780f300e8cfd371e3eb2e52d9c7a30fa6fa9/routes/api.php#L23-L28


	// save sensor data of multiple sensors
	Route::post('sensors', 		'Api\MeasurementController@storeMeasurementData')->middleware('throttle:10,1');
	Route::post('lora_sensors', 'Api\MeasurementController@lora_sensors')->middleware('throttle:100,1');


	// save sensor data of multiple sensors (unsecure)
	Route::post('unsecure_sensors', 'Api\MeasurementController@storeMeasurementData');

snooz · June 10, 2021, 6:00pm

das wäre der Hammer…
ich check das mal

snooz · June 25, 2021, 8:03pm

@clemens

BeepNL scheint irgendwie keine Bock zu haben auf das Issue zu reagieren.

Ich hab das Beep noch nicht auf meinem Ubuntu ans laufen gebracht…

Wer von dem BOB Team hätte denn erstens mal Lust BOB auf die aktuelle Version von BEEP zu aktualisieren und/oder den Code etwas anzupassen?

clemens · June 26, 2021, 7:08pm

@caro und @Diren hatten einige lokale Anpassungen gemacht, daher ist es mit “Drüberinstallieren” leider nicht getan. Und ich denke auch nur sie könnten das in Angriff nehmen.

snooz · June 26, 2021, 9:50pm

naja ich denke, dass wir das ja nicht mal auf die aktuelle Version heben müssten,

Den key time zu unterstützen, wären drei Zeilen Code, die wir aus BEEP 1:1 kopieren könnten.

Ich würde mir dann eben einfach noch wünschen, dass entweder dieser Call nicht nur ein dictionary/json-objekt akzeptiert, sondern auch noch eine Liste von Dictionaries mit Time item drin.
Oder ein anderer POST genutzt wird, diese Array entgegen zu nehmen.

Ich kämpfe gerade echt mit unzuverlässigem WLAN und das nervt total, dass dann halt mal ein Tag oder mehr fehlt, weil ich erst nach dem Wochenende zum Standort komme.
Grad ist der Drecks-AP schon wieder ausgefallen und ich kann erst Mittwoch hin.
Wieder eine Woche keine Daten…