.titleBar { margin-bottom: 5px!important; }

RRDstats und Smart Home

Dieses Thema im Forum "Freetz" wurde erstellt von leo22, 25 Nov. 2018.

  1. leo22

    leo22 Aktives Mitglied

    Registriert seit:
    13 Apr. 2005
    Beiträge:
    902
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Mit dem Paket RRDstats kann ich super mithilfe von 1-wire-Adaptern mit DigiTemp die Raumtemperatur überwachen.

    Derzeit nutze ich jedoch Smart Home und setze Heizkörper-DECT-Regler ein. Im neuen FRITZ!OS 07.01 kann man sich dazu die Temperaturentwicklung der letzten 24 Stunden als Grafik anzeigen lassen. Leider sind die Daten bei Neustart weg, auch können keine längerfristigen Auswertungen vorgenommen werden.

    Ich suche nun nach einer Lösung, die FRITZ!Box-interne Lösung in RRDstats/DigiTemp zu integrieren.

    Zuständig scheinen die Lua-Dateien /var/html/net/home_auto_temp_view.lua und /var/html/net/home_auto_overview.lua zu sein.

    Nun weiß ich nicht recht, wie ich die Daten zu RRDstats bekomme. Hat da jemand eine Idee?
     
  2. hermann72pb

    hermann72pb IPPF-Promi

    Registriert seit:
    6 Nov. 2005
    Beiträge:
    3,611
    Zustimmungen:
    2
    Punkte für Erfolge:
    38
    1. Schreib doch AVM an, dass die es vernünftig machen. Von mir aus auf dem USB-Stick abspeichern, oder wie auch immer.
    2. Die von dir erwähnten lua-Skripte sind vermutlich dazu da, die Daten aus der internen "Datenbank" auszulesen und im AVM-WebIF darzustellen. Man kann sie natürlich irgendwie dazu missbrauchen, um die Werte aus der AVM-Welt herauszufischen und in eine vernünftige abspeicherbare Form (ASCII, Binär, Datenbank) zu bringen, um sie später mit RRDstats darzustellen. Quasi so eine Art Parser-Übersetzer schreiben.
    3. Eine elegantere Methode wäre allerdings, herauszufinden, wo AVM die Werte zur Darstellung speichert. Wenn du Glück hast, legen sie es einfach als Klartext irgendwo im RAM ab (z.B. unter /tmp). Dann wäre es etwas einfacher, die Daten von dort abzugreifen und zu retten und man müsste dann die lua-Skripte von AVM nicht ausführen. Etwas komplizierter wird es, wenn AVM dafür irgendeine Datenbank nutzt.

    Wie du siehst, wird dir keiner die Arbeit abnehmen, die Punkte 1,2 und 3 zu verwirklichen. Vor allem für 3 sind weitere Beobachtungen deinerseits auf dem laufenden System erforderlich.

    MfG
     
  3. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Mal ehrlich ... spätestens auf GitHub kann sich inzwischen wirklich jeder den Trunk klonen und solche Sachen auch tatsächlich so veröffentlichen, daß interessierte Dritte sie auch finden können.

    Immer wieder wird bei irgendwelchen Sachen behauptet, es gäbe sie schon lange und wenn man dann nach einer URL dorthin fragt (Suchmaschinen finden da in aller Regel nichts - wir hatten diese Diskussion schon mal beim Signieren von Firmware-Images), folgt nur noch Schweigen.

    Was bringt es denn, wenn Du irgendwelche Screenshots von Lösungen zeigst, die aber niemand anderes nutzen kann? Wenn damit noch irgendwelche Erklärungen oder eine Anleitung verbunden wäre, hätte das vielleicht auch ohne "Quellen" noch einen Nutzen ... so ist es reines Posen.

    Ich erwähne zwar auch ab und an mal, daß ich bei mir Lösungen im Einsatz habe, die der Öffentlichkeit noch nicht zur Verfügung stehen (meist deshalb, weil sie bar jeder Dokumentation sind und infolge ihrer Entwicklung ohnehin ein Rewrite bräuchten), aber dann in aller Regel nach einem Vorschlag, wie man etwas lösen könnte (und dann macht die Bemerkung, daß man das selbst schon so im Einsatz hat, auch wieder Sinn) ... aber wenn Du da etwas kennst, was bereits die Qualität hat, um in den offiziellen Trunk einzugehen (sonst macht der Hinweis auf die beschränkten Zugriffsrechte beim Schreiben ja wenig Sinn), dann ist das einfach etwas wenig, was Du hier anbietest.

    Selbst wenn diese Lösungen irgendwoanders "herumliegen", verbietet Dir ja wohl niemand, entsprechende Links zu veröffentlichen. Suche ich mit "rrdstats smart home freetz" bei Google (dabei spielt es auch keine Rolle, ob "smart" und "home" zusammen oder getrennt geschrieben werden), finde ich zwar an allererster Stelle auch diesen Thread hier, aber nicht einen einzigen sinnvollen Link auf dieses "hidden Freetz" - das muß ganz, ganz tief im After des Darknet stecken und wohl nur ausgewählten Suchmaschinen zugänglich sein.
     
    f666 gefällt das.
  4. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Das muß Dich ja nicht davon abhalten, so etwas dann anderen auf GitHub zur Verfügung zu stellen (da kann Dir auch niemand die "Schreibrechte" verwehren) ... daß es mit SVN oder Patches hier im Forum nicht das Gelbe vom Ei ist (auch bei deren "Handling" durch die handelnden Personen - und nun ist auch der Trac noch tot, wo man das ansonsten noch hinterlegen konnte, damit es nicht direkt wieder unterging), ist unbestritten.

    Aber schau Dir den Support für die Puma-Boxen an oder auch den Fork von @DHU, in dem FHEM immer noch unterstützt ist ... niemand mußte die erst mit dem Freetz-Trunk mergen, um deren Angebot wahrnehmen zu können. Daß die Puma-Anpassungen es dann erst nach langer Zeit und heftigen Änderungen in den Trunk geschafft haben, steht ja auf einem anderen Blatt.

    Ansonsten reicht es schon, wenn der jeweilige "Besitzer" des Forks seinerseits das Rebase auf den Trunk macht (und notfalls kann man ihn ja auch darauf ansprechen, daß man statt freetz/freetz lieber seinen Fork verwenden würde, der aber gerade nicht aktuell ist im Vergleich zum Trunk und ob er das nicht netterweise ändern könnte) ... bei wichtigen Änderungen zumindest, denn beim "klein-klein" ist mir das tatsächlich auch zu viel, zumal ich das noch alles in Branches sortiert habe, damit man daraus tatsächlich auch einen Pull-Request machen könnte und dann auch jeder dieser Branches wieder sein eigenes "rebase" braucht - am Ende würde jede Änderung im Trunk in meinen Fork mit der Anzahl der offenen Branches multipliziert, wenn ich das tatsächlich immer sofort machen wollte.

    Aber dann checkt der Interessierte eben nicht "freetz/freetz" als Upstream aus, sondern den Fork und dafür muß man von "git" und/oder GitHub nicht wirklich etwas verstehen und auch keine Branches selbst mergen oder Konflikte beheben können. Und selbst wenn er das müßte (also "mischen können") ... solange sich ein fremder Branch mit einer Zeile mischen läßt, ist das durchaus "zumutbar" (man ist ja dann an den Änderungen interessiert und da ist es normal, wenn man dafür ein paar Anstrengungen unternehmen muß) - erst bei "merge conflicts" würde es dann "eklig".

    Wobei das für "einzelne Patches" anstelle eines Forks oder verschiedener Branches ja auch nicht wirklich anders sein kann (ich verstehe Deinen Text so, daß Du das so verwaltest) ... ändert sich im Upstream etwas (und die jüngsten Änderungen an allen möglichen Symbolen haben ja gerne auch Auswirkungen auf (private) Pakete, wenn solche Symbole dort verwendet werden), muß man dann eben die Patches anpassen. Das ist auch nichts anderes, als ein "rebase" für den eigenen Fork.

    Und wenn Du tatsächlich ablehnst, die thematisch zusammengehörenden Änderungen in "feature branches" zu verpacken (ein Auslesen und Speichern von Meßwerten der FRITZ!DECT-Geräte für die spätere Visualisierung wäre ja sicherlich ein solcher), kann es bei der Sourcecode-Verwaltung bei Dir ja nicht viel anders aussehen als im Freetz-Trunk, wo auch jeder Furz direkt in der Version landet, die für die Benutzer gedacht ist ... die Feststellung, daß es sich beim Trunk um die "Entwicklerversion" handeln würde (und man da auch mit Problemen rechnen muß), ist ja am Ende nur ein recht bequemes Mäntelchen über der Tatsache, daß es eben schon lange kein sinnvoll verwendbares Release für aktuelle Boxen mehr gibt und die Leute zwangsweise den Trunk nehmen oder auf Freetz verzichten müssen. Es hat schon seine Gründe, warum Neulinge immer wieder mit Freetz 2.0 starten wollen ... weil ein Projekt, das nur noch aus der aktuellen Entwicklerversion besteht, eben schon recht ungewöhnlich ist und viele lieber eine echte "stable"-Version hätten, als das Risiko einzugehen, daß es am Ende dann doch nicht klappt und sie gar nicht so richtig wissen, ob das nun an ihnen oder an der "Qualität" der Entwicklerversion liegt. Gerade für Anfänger ist das natürlich ein ziemliches Brett ... da wäre eine "garantiert lauffähige Version" (wie man es von einer "stable" erwarten darf) dann schon der bessere "Einstieg".

    -----------------------------------------------------------------------------------------------------------

    Das mit dem "single branch" hat Vorteile (weil Changes zur Fehlerkorrektur unmittelbar verfügbar sind) und es hat auch Nachteile (weil alle Changes unmittelbar verfügbar sind und auch für alle wirken, selbst wenn sie "compile-tested only" sind) - solange es sich fast nur noch um die "Verwaltung" des bisherigen Zustands handelt, bei dem ältere Versionen von neueren abgelöst werden, ist das aber auch egal.

    Spannend (und störend für Freetz-Benutzer) wird dieses Vorgehen erst dann, wenn man wirklich Neues einbauen will und das tiefgreifende Änderungen an Vorhandenem erfordert, ohne daß man das Ende schon absehen kann (das geht nun mal nur, wenn das kein wirklich großer Sprung ist, denn das hat mit der Fähigkeit zur "Voraussicht" auch nur bedingt zu tun) ... da muß dann auch mal der "Irrtum" möglich sein, der sich eben nicht gleich negativ auf alle anderen Benutzer auswirkt und wo sich ein solcher dann auch bewußt dafür oder dagegen entscheiden kann, ob er ein neues Feature nun einbauen (und damit dann auch testen) will oder nicht.

    -----------------------------------------------------------------------------------------------------------

    Ja, ich habe auch genug Konflikte an dieser Stelle ausgefochten ... das hindert mich aber nicht daran, meine Ergebnisse (oder auch die Ideen bzw. "Prinziplösungen", wobei ich da tatsächlich deutlich zurückhaltender geworden bin, weil ich die meisten schon gerne selbst umsetzen möchte) dann anderen auch zur Verfügung zu stellen.

    Was bringt es, wenn ich die nur bei mir herumliegen habe und andere sie nicht nutzen können? Wir reden hier ja immer noch von kompletten und fertigen Lösungen (so habe ich Dich verstanden) und nicht von irgendwelchen "Beispielen", wie man etwas lösen könnte (oder auch nicht) und wo eine "Veröffentlichung" dann eher für Verwirrung sorgen könnte, als daß sie hilfreich wäre.

    So, wie Du das im Moment machst, erinnert es mich etwas an die "Gründerszene", wo mit (durchaus guten) Ideen und Photoshop dann erst mal das passende "Bild" zur Lösung gebaut wird, weil sich die Leute (aka potentiellen Investoren) das dann viel besser vorstellen können. Da weiß kein Aas, ob das Versprochene überhaupt am Ende einzulösen ist und ob die Idee funktioniert ... aber "sehen" kann man trotzdem schon mal etwas, bevor man sein Kapital (das heißt ja nicht umsonst "Risikokapital") investiert. Nur wenn das dann mal "vorzuzeigen" wäre in Funktion, ist immer irgendetwas anderes, was das gerade verhindert ... aber das soll ja selbst richtig großen Firmen bei ihren Präsentationen auf offener Bühne schon mal passiert sein.