Stabile Telemetriefeldnamen für dynamische Dashboards

Entwicklung / Development Firmwareschmiede / Firmware development
1

Bei Dashboards für mehrere Völker an einem Standort ergibt sich auch ein Problem mit der neuen hiveeyes-Firmware:

Doof ist nun der Umgang mit den DS18B20. Früher habe ich die Variablen brutraum-1, brutraum-2 usw. genannt und sie waren damit für alle Stöcke gleich und konnten daher auch für alle “drop-down”-Stöcke verwendet werden. Nun hat der Variablenname aber die Hardware-Sensor-ID im Variablenname, z.B. temperature.28030f2509000057.onewire:0, damit geht’s nicht mehr. In der hiveeyes-settings.py hatte ich schon eine description vergeben. Besser wäre diese als Sensorname, der wird aber bisher gar nicht übertragen, oder @Andreas?

2

Vielen Dank für die Meldung.

Verstanden. Schade!

Also related:

3

Drüben bei Erarbeitung eines kanonischen Datenschemas für imkerliche Meßdaten haben wir mit dieser Tabelle gezeigt, wie wir hier wieder besser werden könnten.

Sensor/Telemetry Database Grafana
temperature.0x77.i2c:0 temperature.inside Temperatur Innen
temperature.28ff641d8fc3944f.onewire:0 temperature.body:1 Temperatur Brutraum 1
temperature.28ff641d8fdf18c1.onewire:0 temperature.body:2 Temperatur Brutraum 2
temperature.28ff641d8fa1b2c3.onewire:0 temperature.super:1 Temperatur Honigraum 1
temperature.28ff641d8fd4e5f6.onewire:0 temperature.super:2 Temperatur Honigraum 2

Mindestens müssten Mechanismen geschaffen werden, die vom aktuellen Sensornamen auf einen kanonischen Feldnamen à la "temperature.body:2" mappen. Mit diesem wäre dann die Feldnamenbezeichnung über verschiedene Stöcke hinweg wieder stabil, was bei der Gestaltung des Dashboards hinsichtlich entsprechender Navigation entgegenkommt.

Bei Sending telemetry data to different backends haben wir das schon für die richtige Umsetzung zu den Telemetriefeldnamen für BEEP realisiert, an dieser Stelle müssten wir nun also eine Stufe generalisitischer werden.

2 Likes
4

Auch das wäre als Alternative absolut denkbar, plausibel und sinnvoll. In diesem Fall fallen die beiden in obiger Tabelle dargestellten letzten Spalten in eine einzige zusammen.

2 Likes
5

Wo wurden wir das machen, bisher hatte ich die Idee die Variablen in der Firmware entsprechend umzubenennen oder description oder sensor -id statt des jetzigen Variablennamens zu verwenden. Macht das Sinn? Oder wäre das Mapping der kanonischen Feldnamen besser bei Grafana untergebracht?

6

Hi Clemens,
Wär sicherlich in der Firmware am besten untergebracht. Im Endeffekt genau wie das Mapping der Sensornamen von Bob.
Steht auch schon hier auch unter Prio2 [Backlog] Terkin-Datenlogger für BOB

Man müsste dann entweder mehre Maps anlegen und dann jedem Telemetrie-ziel sagen welche Map es benutzen soll.
Oder halt für jedes Telemetrie-Ziel eine eigenständige Map anlegen.

So werden dann so einige Sachen Möglich

  • 1x Node für 2 Bienenstöcke
  • nach austausch eines defekten DS1820 kein tricksen mit den älteren Datensätzen nötig.
  • Nicht benötigte Daten werden gar nicht erst übertragen (weniger Datenvolumen)
  • Beliebige Benennung der Sensoren in der DB für universelle/instant Dashboards.
  • Einzelne Datensätze könnten zusätzlich separat an andere Server übertragen werden (z.B. Wetter)
2 Likes