Die realtime api verbindet sich per websocket mit der tibber cloud und fragt die werte ab, die der pulse liefert. Also ja, offizielle cloud api von tibber.
Hallo Chris (auch philipp),
danke für das Modul, funktioniert einwandfrei.
Gestern in weniger als 5 Minuten eingerichtet.
Gruß Achim
1 „Gefällt mir“
Dann scheint mir die inoffizielle Variante mit dem Websocket direkt auf dem Gateway aber sinnvoller zu sein, da ich dann nicht erst den Umweg übers Netz gehen muss.
Auf jeden Fall danke für das Modul! 
Hi,
Klar, aber wie du schreibst ist das inoffiziell, kann also seitens tibber auch einkassiert werden. Ausserdem ist das hier halt einfach, weil es einfach ist 
Ist ja auch super, dass du es anbietest und war überhaupt nicht als Kritik am Modul gedacht (solltest du dies so aufgefasst haben ), sondern eher an den Schnittstellen von Tibber. Statt einzig eine Webschnittstelle anzubieten, sollten sie doch lieber auf die ohnehin vorhandenen lokale Schnittstelle setzen und diese offiziell anbieten, die dann viel performanter und stabiler ist.
Aber das ist ja heute oft so, dass die Daten erst einmal um die Welt geschickt werden, statt sie direkt vor Ort an der Quelle anzubieten, wo sie am Ende oft gebraucht werden.
Nene. Ich hab es nicht als kritik aufgefasst. Für das „native“ tibber gibt es wohl schon was.
Viele grüsse
Ich habe gestern das Modul installiert und muss sagen: Hochachtung! Alles funktioniert „out of the box“. Das hat richtig Spass gemacht. Vielen Dank an alle Beteiligte!
Hi,
als erstes einmal vielen Dank für das spitzenmäßige Modul.
Soeben innerhalb von 5 Minuten zum Laufen gebracht, lüppt wie am Schnürchen, aber ich habe ein Problem:
Der eingesetzte Zähler ist ein
EBZ DD3 2R06 ETA ODZ1
liefert die Daten im alten Format, leider nicht die Ströme der einzelnen Phasen, nein, er sendet
OBIS Werte, hier die einzelnen Momentanleistungen 36.7.0, 56.7.0 und 76.7.0 !
Die kennt die Tibber API aber nicht, oder?
mfg
Bernd Jung
Hi,
Du könntest unter Tibber Developer deinen token eintragen und dann rechts beim button „load an example“ dir die realtimesubscription anschauen (nicht vergessen links auf den play button drücken)… ich denke aber nicht dass das die cloud hergibt.
Ggf könntest du versuchen die lokale bridge direkt anzuzapfen und das obis modul zu nutzen… dazu gibt es einen extra thread.
Trage doch einfach deine Zählernummer hier ein und schau, ob der Zähler überhaupt kompatibel zum Pulse ist …
…, auf der Whitelist für den Pulse steht er so zumindest drin.
Musst aber ggf. noch mal den Hinweis hinten beachten …
Der zähler wird doch auch erkannt aber berndj möchte mehr werte als, wahrscheinlich, tibber liefert.
Hatte es so verstanden, daß die Tibber API seine Daten vom Zähler nicht versteht, bzw. er das prüfen wollte.
Hi,
@kris
Danke für den Tip.
Die API liefert folgendes:
„timestamp“: „2023-11-07T23:05:16.000+01:00“,
„power“: 343,
„accumulatedConsumption“: 8.619766,
„accumulatedCost“: null,
„currency“: null,
„minPower“: 201,
„averagePower“: 373.3,
„maxPower“: 2573
Also ein Problem mit der API von Tibber, welche den hoffentlich gelieferten Leistungswert der einzelnen Phase nicht übernimmt; denn der Netzbetreiber hatte zugesichert dass dieser die o.g. Werte zur Verfügung stellt.
Mein Problem: der Zähler ist 40 km entfernt, also kurz mal einen Volkszähler Kopf rauf und sehen was kommt geht nicht.
Muss wohl mal schauen wie ich schnell an die Daten der Pulse Bridge komme.
mfg
Bernd Jung
BTW: hab gegen 19 Uhr ne Anfrage an Tibber gestellt ob sie diese OBIS mit aufnehmen können; denn die möglichen Stromwerte der einzelnen Phasen sind ja im Grunde genommen nicht aussagefähig wenn man keine Ahnung hat wo die jeweiligen Werte der Phasenverschiebung liegen. Da halte ich saubere Leistungswerte jeder Phase für wesentlich eleganter.
Hi @all,
grad den nächsten Fehler von mir erkannt:
Im API Explorer sind bei den Examples nicht alle Möglichkeiten auf der linken Seite aufgelistet!
daher liefert die Antwort auf der rechten Seite natürlich nur die links angefragten Werte.
Also ergänzt um:
powerFactor
voltagePhase1
voltagePhase2
voltagePhase3
currentL1
currentL2
currentL3
und schon kommen auch hier einige Werte:
„timestamp“: „2023-11-07T23:33:04.000+01:00“,
„power“: 598,
„accumulatedConsumption“: 8.810327,
„accumulatedCost“: null,
„currency“: null,
„minPower“: 201,
„averagePower“: 374,
„maxPower“: 2573,
„powerFactor“: null,
„voltagePhase1“: 235.9,
„voltagePhase2“: 234.5,
„voltagePhase3“: 237.2,
„currentL1“: null,
„currentL2“: null,
„currentL3“: null
überall wo als Ergebnis: null erscheint bekommt Tibber keine Werte vom Pulse.
Der Versuch powerL1 als zusätzlichen Abfragewert zu setzen wird bereits beim Aufruf mit einer Fehlermeldung belohnt.
Schön beim Versuch etwas einzugeben ist die zusätzliche Einblendung von Befehlen; leider ist da nicht mehr ausser power.
Also ran an die Daten der Pulse Bridge voller Hoffnung das der Tibber Progger schneller sein könnte.
mfg
Bernd
Hi,
es geht weiter.
Ich vermute mal für den direkten Zugriff meint Ihr das Modul Counter Obis mit dem Untermodul HTTP Client.
Hat einer nen Tip auf welchem Port man die Verbindung aufbauen muss?
mfg
Bernd
Hi,
ich habe die Version 1.4 im Beta-Kanal. Diese wird, wenn keine Fehler auftreten, als Release Candidate veröffentlicht.
- README wurde angepaßt und vervollständigt
- Die zwei Funktionen GetHomesData() und CheckRealtimeEnabled() waren „normal“ nutzbare Funktionen, machen aber außerhalb des Moduls keinen Sinn und sind nun private funktionen
2 „Gefällt mir“
Hi Kris,
als erstes vielen Dank, geiles Modul.
Bis vor dem letzten Update stieg bei mir das Realtime-Modul immer um 12,52 Uhr aus.
Wohlbemerkt bei 2 unterschiedlichen Tibber Accounts,
einer von beiden wurde mit 2 unterschiedlichen IP WAN Adressen doppelt abgefragt;
immer exakt derselbe Zeitpunkt.
Jetzt nach dem letztem Update dachte ich: Klasse, Fehler beseitigt!
Bis jetzt um 14,41 Uhr, keine Aktualisierung mehr.
Rein in die Management Console des ersten Rechners auf welchem beide laufen:
Beim ersten tibber Account Schnittstelle schliessen → speichern → öffnen → speichern: und schon trudeln wieder Daten ein!
Diese Routine half auch vorher, war aber täglich um exakt dieselbe Uhrzeit nötig.
Zweiter Account auf erstem Rechner: keine Daten, same Procedure, lüppt!
Rüber in die Console des entfernten Rechner via VPN:
Huch, ist von alleine wieder losgelaufen,
vermutlich durch die Aktion auf dem ersten Rechner.
Bin ich der einzige mit diesem Problem?
mfg
Bernd
Moin,
Das verwirrt mich gerade… Also du hast zwei Accounts, ein Account benutzt zwei unterschiedliche Wan Adressen?
Es gibt zwei Limitierungen…
- max. 100 Anfragen innerhalb von 5 min. pro (externe) IP Adresse
- max 2 gleichzeitige Websocketverbindungen pro Account
das hört sich tatsächlich so an, als würde er in ein limit laufen oder aus einem anderem Grund die Verbindung verlieren.
Das ist komisch. Der Rechner wird ja eine andere IP und einen anderen Account haben, oder nicht?
Ich habe so ein Problem nicht, bei mir verliert er durch das testen die Verbindung und baut sie nicht mehr auf.
Das wollte ich noch robuster machen, auch das wenn einige Zeit lang keine Daten kommen, soll der Websocket automatisch geschlossen und wieder neu geöffnet werden (was dein Problem zum Teil lösen könnte).
Viele Grüße
Hi Kris,
der zweite Rechner (natürlich entfernt und anderer Provider) nutzt denselben Account, welcher als Nr.2 des ersten Rechners gesetzt ist.
Heute um die von mir genannte Zeit keinen Stillstand bei Deinen Daten gehabt?,
habe irgend wie das Gefühl in der Magengegend dass Tibber da ein unerfreuliches Script am Laufen hat.
Hilft es evtl. wenn in das Modul ein kurzes Neuverbinden alle 48 Stunden eingebunden wird?
mfg
Bernd