@thegrinch said in Test Adapter TibberConnect 0.0.x inkl. Tibber Pulse:

@oxident so wie ich das auf tibber.de gelesen habe, machen die stündliche Abrechnung nur mit dem Pulse. Hätte also nur einen Effekt für die monatliche Übermittlung, wenn es denn akzeptiert wird.

Exakt. Die ursprüngliche Frage war ja, ob/wie man Werte hochladen kann, anstatt sie monatlich selbst in die App einzugeben, wenn man keinen Pulse hat. Da ich vor dem selben Problem stehe, bis mein Pulse ankommt und bis ich weiß, dass er mit meinem Zähler kompatibel ist, habe ich mich damit mal beschäftigt.

Mit einem funktionierenden Pulse erledigt sich das Thema natürlich komplett.

@Schimi @oxident

Hat noch ein wenig gedauert, bis es "rund" ist. Hier ist ein erster Release meines Tools, welches aktuell die Zäherstände über ein Shell-Script beziehen kann:

https://github.com/micw/tibber-meter-uploader

Läuft seit heute bei mir auf dem Server unter Docker und hat heute den ersten Wert hochgeladen. Fehlermeldungen, Feature-Requests und Diskussion ist willkommem

Viele Grüße,
Michael.

@pavelcoast said in Test Adapter TibberConnect 0.0.x inkl. Tibber Pulse:

Soll zwar nur für Norweger sein, aber vielleicht funktioniert es auch hier, dann könnte man täglich den Zählerstand automatisiert senden, statt über die App.

Leider nicht:

Dazu müsste man sich die App mal anschauen und die private API herausfinden.

Edit: Hab mir die App mal angeschaut und die private API herausgefunden ^^

https://app.tibber.com/v4/gql

Beispiele:

Auth-Info:

{
  me {
    id
    firstName
    homes {
      id
    }
  }
}

Aktueller Zähler:

{
  me {
    home(id:"xxxxxx-xxxxxx-xxxxxx-xxxxx") {
      currentMeter {
        id
        meterNo
        isUserRead
      }
    }
  }
}

Zähler und Register anzeigen:

{
  me {
    meters {
      items {
        type
        title
        meter {
          id
          readingDateScreen {
            title
            nextButtonText
          }
          registers {
            id
            title
            description
            expectedMin
            expectedMax
          }
        }
      }
    }
  }
}

Zählerstand eintragen

mutation {
  me {
    addMeterReadings(meterId: "xxxxx-xxxxx-xxxxx-xxxx-xxxxxxxx",readingDate: "2023-01-16", readings: [{id:"1-0:1.8.0",value:26529}])
    {
      success {
        inputTitle
        inputValue
        title
        descriptionHtml
        doneButtonText
      }
      error {
        statusCode
        title
        message
      }
    }
  }
}

Viel Spaß damit

@schimi Hab leider mit IOBroker gar nix zu tun und auch keine Ahnung, wie das rein geht. Technisch ist es am Ende recht einfach.

Zuerst sende ich einen HTTP-Request mit Username+Passwort und bekomme einen Login-Token.

Dann sende einen HTTP-Request mit einer GraphQL Query. Das ist ein JSON-Dokument, welches in einem Feld eine Query (das ist ein großer statischer Text) und in einem anderen Feld alle Variablen enthält. In einem Cookie-Header sende sich das Login-Token mit. Als Antwort bekomme ich eine Info über den Account, alle Zähler, deren "Register" (da ist nur das Register "1-0:1.8.0" interessant, das ist der Gesamtstromverbrauch über alle Phasen und Tarife) und alle "Homes", jeweils nochmal mit deren Zählern und den zuletzt gemeldeten Zählerständen.

Das JSON-Objekt zerlege ich, so dass ich weiß, welcher Zähler dort ist und welche Zählerstände gemeldet sind.

Mit diesen Infos befrage ich die "Quelle" - das könnte beispielweise auch IOBroker sein - nach neuen Zählerständen ab dem letzten gemeldeten. Ich übertrage hier tageweise, obwohl monatlich ausreichen würde, da ich gerne die Statistik in der Tibber-App sehen möchte (das kann ich aber auf Wunsch auch einstellbar machen).

Habe ich die Zählerstände, rufe ich eine GraphQL "Mutation" auf, um die zu übergeben. Funktioniert genau wie die GraphQL Query.

Mit diesen Infos und dem Code aus meinem Repo sollte es jemanden mit entsprechenden Kenntnissen sicher möglich sein, das auch direkt in IOBroker umzusetzen. Alternativ (wenn mir jemand sagt, wie ich das abfrage und es hinterher testet), kann ich auch direkt IOBroker als Quelle mit in mein Tool einbauen. Bei Bedarf bitte ein Ticket mit den nötigen Infos im Repo machen.

Viele Grüße,
Michael.

Edit: ich würde mich mit diesem Post aus dem Thread ausklinken, da das hier nur so halb reinpasst und ich den Thread damit nicht kapern möchte. Wenn es einen Thread gibt, das Senden der Daten in IOBroker zu integrieren und Rückfragen sind, kann ich gerne angepingt werden.

@ostseeskipper Das geht, wenn beide Köpfe das gleiche Signallevel haben (z.B. beide RS232 oder beide TTL-UART).
Wenn der Kopf direkt USB hat, geht's nicht, dann musst du das Signal vorher abgreifen.

Wenn du das nur auf USB ausgeben möchtest, benötigst Du:

einen der Leseköpfe, mit IR-Transistor bestückt (auf Zähler)
einen der Leseköpfe, mit IR-Diode auf Sendeseite bestückt (gibt das Blinken am Pulse weiter)
einen USB-TTL-Adapter (für 2-3€). Kann beide Leseköpfe mit Strom versorgen ind direkt an RX angeschlossen werden.

Das Setup (bis auf den Pulse) habe ich hier schon als Prototyp getestet. Läuft einwandfrei, auf USB kommt dann SML mit 9600 Baud an.

@ostseeskipper Schematics sind fertig, PCB auch. Ich warte noch auf meinen neuen Pulse (ist heute verschickt worden), um meinen Prototyp hier zu testen, wenn alles geht bestelle ich die Boards.

Edit: ich bestelle die Platinen incl. Bestückung bei JLCPCB. Da wird alles drauf sein, außer dem IR-Transistor und einer LED+Vorwiderstand zum senden und Kabel/Stecker. Da habe ich Durchsteck-Komponenten geplant, so dass man die einfach per Hand löten kann.

@ostseeskipper Nee, die mit den eigenen Lese-Schreibköpfen.

Den reader hatte ich davor. Nachteil ist, dass man den Pulse modifizierne muss (Webserver immer an). Erstens benötigt der Ressourcen auf dem eh schon recht ausgelasteten ESP32. Zweitens kann Tibber die Funktion jederzeit rauspatchen. Gleiches gilt für den zwischengeschalteten Broker.

Daher finde ich eine Hardwarelösung auf Dauer besser, insb. wenn man sein Lastmanagement dranhängen hat.

@ostseeskipper Die Idee ist nicht von mir. Jemand hat einfach nen Lese/Schreibkopf an einen anderen gelötet (in/out vertauscht), um das zu realisieren. Mit 2 kommerziellen Köpfen war mir das aber zu sperrig und zu teuer, daher die Projektidee. Die Kopie ist rein elektronisch auf Signallevel ohne "logische" Komponenten dazwischen.

Eine Gefahr für die Zukunft des Pulse sehe ich hier nicht. Wenn jemand genug Know-How hat, das Signal abzugreifen, zu fälschen und wieder einzuspielen, braucht er das Projekt nicht und könnte dafür ganz normale, kommerzielle Leseköpfe verwenden. Einen gewissen Prozentsatz an Betrügern gibt's sicher überall, das wird bei der Stromabrechnung nicht mehr oder weniger sein als anderswo.

Moin. Das sollte prinzipiell auch mit der deutschen Tibber Bridge gehen. Hab mir die vor ein paar Wochen mal angeschaut und verbloggt: https://blog.wyraz.de/allgemein/a-brief-analysis-of-the-tibber-pulse-bridge/

Alternativ kann man den Webserver dauerhaft einschalten und die Daten darüber pollen. Das greift nicht in die MQTT-Kommunikation ein und ist leichter zu setuppen. Mein Projekt dazu: https://github.com/micw/tibber-pulse-reader

Leider ist mein Pulse kaputt (hat von Tag 1 keine Updates angenommen, nachdem ich den von Tibber empfohlenen Werksreset gemacht habe, geht garnix mehr). Darum habe ich mal rumgeschaut, wie man das unabhängig vom Pulse machen kann und habe ein Stück Hardware entworfen, welches per IR die Daten ließt, das ganze (rein elektronisch) wieder als IR ausgibt (so dass man den Pulse anschließen kann) und die Daten zusätzlich lokal bereit stellt (per eigenem IR-Kopf, per USB-TTL-Adapter und/oder per aufgelötetem ESP8266). Herausgekommen ist ein einfacher, supergünstiger Lesekopf sowie ein Board, um die Signale zu "klonen": https://github.com/evcc-io/evcc/discussions/7070

@crunchip ChatGPT generiert "syntaktisch korrekte Sätze", was auch für Programmiercode gilt - auch der ist nach dem Verständnis von ChatGPT Syntax und es generiert dort syntaktisch plausiblen Code.

ChatGPT generiert jedoch nicht zwingend inhaltlich/fachlich korrekte Dinge. In vielen Fällen fließt korrektes Wissen mit ein, so dass tatsächlich verblüffende Ergebnisse heraus kommen, an anderen Stellen werden aber auch einfach Fakten "erfunden", so dass wieder syntaktisch korrekte und schlüssige Aussagen herauskommen.

So auch in dem Beispiel. Ein Blick auf https://developer.tibber.com/docs/reference zeigt, dass es keine Funktion "updateDataPoint" gibt und dass "sendMeterRrading" nur für Norwegen freigeschaltet ist. Damit kann das Script nicht funktionieren.

Man kann die Monatswerte über die API übermitteln, welche auch die APP verwendet. Diese ist nicht offiziell, unter https://app.tibber.com/ bzw. https://app.tibber.com/v4/gql steht aber eine automatisch generierte Doku bereit. Wie man darüber Monatswerte einstellt, habe ich oben beschrieben und in meinem Tool implementiert. Ich denke, dass sich das auch verhältnismäßig einfach mit so einem JavaScript-Fragment in IOBroker umsetzen ließe.

Viele Grüße,
Michael.

@schimi Hab leider mit IOBroker gar nix zu tun und auch keine Ahnung, wie das rein geht. Technisch ist es am Ende recht einfach.

Zuerst sende ich einen HTTP-Request mit Username+Passwort und bekomme einen Login-Token.

Dann sende einen HTTP-Request mit einer GraphQL Query. Das ist ein JSON-Dokument, welches in einem Feld eine Query (das ist ein großer statischer Text) und in einem anderen Feld alle Variablen enthält. In einem Cookie-Header sende sich das Login-Token mit. Als Antwort bekomme ich eine Info über den Account, alle Zähler, deren "Register" (da ist nur das Register "1-0:1.8.0" interessant, das ist der Gesamtstromverbrauch über alle Phasen und Tarife) und alle "Homes", jeweils nochmal mit deren Zählern und den zuletzt gemeldeten Zählerständen.

Das JSON-Objekt zerlege ich, so dass ich weiß, welcher Zähler dort ist und welche Zählerstände gemeldet sind.

Mit diesen Infos befrage ich die "Quelle" - das könnte beispielweise auch IOBroker sein - nach neuen Zählerständen ab dem letzten gemeldeten. Ich übertrage hier tageweise, obwohl monatlich ausreichen würde, da ich gerne die Statistik in der Tibber-App sehen möchte (das kann ich aber auf Wunsch auch einstellbar machen).

Habe ich die Zählerstände, rufe ich eine GraphQL "Mutation" auf, um die zu übergeben. Funktioniert genau wie die GraphQL Query.

Mit diesen Infos und dem Code aus meinem Repo sollte es jemanden mit entsprechenden Kenntnissen sicher möglich sein, das auch direkt in IOBroker umzusetzen. Alternativ (wenn mir jemand sagt, wie ich das abfrage und es hinterher testet), kann ich auch direkt IOBroker als Quelle mit in mein Tool einbauen. Bei Bedarf bitte ein Ticket mit den nötigen Infos im Repo machen.

Viele Grüße,
Michael.

Edit: ich würde mich mit diesem Post aus dem Thread ausklinken, da das hier nur so halb reinpasst und ich den Thread damit nicht kapern möchte. Wenn es einen Thread gibt, das Senden der Daten in IOBroker zu integrieren und Rückfragen sind, kann ich gerne angepingt werden.

@Schimi @oxident

Hat noch ein wenig gedauert, bis es "rund" ist. Hier ist ein erster Release meines Tools, welches aktuell die Zäherstände über ein Shell-Script beziehen kann:

https://github.com/micw/tibber-meter-uploader

Läuft seit heute bei mir auf dem Server unter Docker und hat heute den ersten Wert hochgeladen. Fehlermeldungen, Feature-Requests und Diskussion ist willkommem

Viele Grüße,
Michael.

@schimi

Welche Möglichkeit gibt es denn, die abzurufen?