Hallo zusammen,

ich freue mich Euch mit tibber meinen ersten Anlauf für einen ioBroker adapter zum testen bereitzustellen:

NPM Link | https://www.npmjs.com/package/iobroker.tibber
Github Link | https://github.com/Magnus8513/ioBroker.tibber

Aktuell werden durch den Adapter stündlich die variablen Preisinfos für die über die Tibber API eingeholt und in entsprechenden states bereitgestellt. Hierfür ist lediglich der persönliche Tibber token zu hinterlegen.

Ich habe noch eine handvoll Ideen was ich noch gerne integrieren möchte, und werde diese hier noch ergänzen.

Ich freue mich auf Euer Feedback. Gerne könnt Ihr auch direkt im GitHub issues aufmachen.

Report Issue via GitHub

Link zur Diskussion auf GitHub zum Adapter Request

Feature Ideen bisher:

• (new) Zählerstände zurück pushen die über andere Adapter erfasst werden
• (new) generell weitere (Meta)-Daten die aus der API Schnittstelle kommen und bereitstellen
• (new) dynamische Berechnung der Ersparnis durch eine stündliche Abrechnung bei entsprechender Lastverschiebung
• (ready for testing starting ab v0.2.0-beta) eine komfortable Lösung um anderen Adaptern leicht die beste Zeit zum Laufen in den nächsten x stunden zurück zu melden.
• Eure Ideen...

Viele Grüße,
Magnus

@malz1902 gut zu hören, dass es läuft.

bzgl. der Meldung über die API ist mit nicht bekannt, dass Tibber das unterstützt für die stundenweise Abrechnung.

Ich meine gelesen zu habend, dass es eine Möglichkeit über die API einen Wert zu Tibber zu übertragen gibt - das habe ich noch nicht testen können, da bei mir die Werte bereits sekündlich via Discovergy an tibber gehen.

Ob Sie das allerdings anerkennen um darüber dann stündlich abzurechnen weiß ich nicht. Ich meine aber, dass sie grundsätzlich immerhin tagesgenaue Preise anbieten und selbst dafür würde sich ein regelmäßiger Übertrag ja dann schon lohnen. Ich schreib mir das mal auf die Feature-Wunsch-Liste

Viele Grüße
Magnus

@michaelnorge ja, genauso in Deutschland.

@thomas-kohb hi, sorry fürs vertrösten, schaffe es gerade nicht mich an das Thema dran zu setzten und habe adhoc auch keine Idee wo es hier bei Dir hakt.

Hat einer von den Nutzern bei denen es läuft eine Idee wo hier das Problem liegen könnte bei Thomas und kann helfen?

@michaelnorge na dann schau ich mir das doch mal als erstes an und sehe zu, dass ich das schon mal einbau. komme dann ggf. nochmal zum testen auf dich zurück weil ich selbst hier in DE noch kein pulse habe, sondern über discovergy daten bekomme.

@Andreas-Del-Galdo , @Thomas-Kohb : Hallo zusammen, sorry für die verzögerte Rückmeldung. Schaue mir das spätestens am Wochende mal genauer an wo es hier hängt.

@Michaelnorge : steht auf der todo liste. habe allerdings noch nicht ganz die passende idee wie ich das am besten in der datenstruktur abbilde. Den aktuellen wert in einen Datenpunkt ist sicher klar, aber was mache ich mit der historie? das erzeugt ja schnell sehr viele Datenpunkte im Adapter. Bin nicht sicher ob das so design good practice ist. Hast Du einen Vorschlag?

@michaelnorge gesehen und hoffentlich auch behoben. GitHub hat mich sofort benachrichtigt, das forum hier leider nicht - glaube aber gerade die passende Einstellung gefunden zu haben um demnächst direkt benachrichtig zu werden.

@michaelnorge ja, genauso in Deutschland.

Gerade ist Version 0.3.0-beta online gegangen. Hierbei habe ich zu den stündlichen Werten das "price level" hinzugefügt, welches tibber über die API liefert.

Zum Verständnis zitiere ich hierzu hier einmal die API Doku zum "Level"

Price level based on trailing price average (3 days for hourly values and 30 days for daily values)

NORMAL
The price is greater than 90 % and smaller than 115 % compared to average price.

CHEAP
The price is greater than 60 % and smaller or equal to 90 % compared to average price.

VERY_CHEAP
The price is smaller or equal to 60 % compared to average price.

EXPENSIVE
The price is greater or equal to 115 % and smaller than 140 % compared to average price.

VERY_EXPENSIVE
The price is greater or equal to 140 % compared to average price.

Dies nutze ich selbst neben den absoluten Werten um regelmäßig und wiederkehrende verschiebbare Verbraucher zu steuern. Dazu gehören bei mir etwa:

• KWL (kontrollierte Wohnraumlüftung)
• Ladegeräte für Ebikes
• Heizungen von Wasserbetten

Ich bin gespannt auf Eure Berichte über Verwendungen des Adapters.

Viele Grüße
Magnus

Magnus 1
@michaelnorge : Hallo Michael, bitte entschuldige die späte Rückmeldung. Mir muss die Benachrichtigung hierzu durchgegangen sein.

Das Problem mit dem Cronstring habe ich so ebenfalls und diskutiere das in einem Thread im developer Bereich hier ebenfalls. Es wurde inzwischen ein issue diesbezüglich eröffnet, weil hier wohl etwas nicht funktioniert wie es sollte. In dem unten verlinkten Thread findet sich ebenfalls eine Beschreibung wie ich das Problem welches Du hier auch zu haben scheinst, zumindest temporär gelöst habe.

Blocky Cron löst nicht aus

Falls Dir das so noch nicht weiter hilft, melde Dich doch gerne nochmal. Ich habe inzwischen zahlreiche Elemente bei mir zu Hause "lastverschoben" mit dem input aus dem tibber adapter hier und teile gerne mehr falls hilfreich.

@dom-sch said in Blocky one time cron löst nicht aus.:

@magnus-1

Vielleicht kannst du hiermit was anfangen ...

Verstanden. Ist ja im Effekt analog zum Vorschlag von Homoran um ein Cron zu bauen was in deinem Fall täglich laufen würde.

Ich werde so erstmal weiter machen, aber frage weiterhin wie ich denn eine einmalige terminierung wie es der Wizzard suggeriert realisiere.

Und: Das ist dann im Ergebnis ein Bug des Wizzards in blocky aktuell, korrekt? Kann mir jemand einen Hinweis geben wo ich diesen am besten dokumentiere?

@dom-sch said in Blocky one time cron löst nicht aus.:

@magnus-1 dann hast du einen Datenpunkt in dem die berechnete Zeit steht, oder kannst das so einrichten ?

ja habe ich. geht es damit direkter? Bisher habe ich mir aus dem DateTime was ich habe, dann den o.g. cron string der ja leider nicht funktioniert zusammengebaut. Wenn ich da auch direkt ein DateTime rein füttern kann, wäre das natürlich noch leichter. Geht das?

@homoran said in Blocky one time cron löst nicht aus.:

55 10 09 16 * naja, alle Jahre wieder

ok, das verstehe ich, es funktioniert in dem testscript und in der Praxis meines eigentlichen scritps vermutlich auch, weil der nie länger als ein Jahr halten wird. Gibt es denn auch die möglichkeit einen echten "einmaligen" pattern zu erzeigen wie es der wizzard suggeriert? Ich habe dazu leider keine doku finden können bisher - ist halt dann eher ein atd als ein cronjob, das habe ich aber im blocky nicht finden können.