Abfrageintervall?

[mdkeil]

Hallo,

erst einmal vielen Dank für das Projekt!

Ich nutze einige Monate recht problemlos die Variante mit einem Hichi-USB-IR Kopf in Verbindung mit einem parallelen TTL-Lesekopf, wo der Tibber-Pulse dran hängt. Bis letzten Freitag hat dies auch über einige Monate funktioniert-- Aktuell ließt der Pulse die Daten für max. eine Stunde stabil aus und scheint sich dann irgendwie aufzuhängen-- ich muss dann den Pulse neu positionieren dann geht es wieder.. habe bereits unterschiedliche Entfernungen/Positionen ausprobiert, ohne Erfolg.. Heute bekomme ich neue Lithium-Akkus, in der Hoffnung, dass es an der Spannungsversorgung liegt.. sollte dies auch nicht funktionieren, werde ich den Webzugang der Bridge freischalten und mir die Daten lokal holen..

Nun die entscheidende Frage: Ich benötige die Daten möglichst in der Aktualisierungsrate vom Zähler, die bei knapp 1s liegt-- liegen die Daten in der gleichen Geschwindigkeit auf der Bridge vor und können entsprechend sekündlich abgerufen werden?

Es wird ja ein minimales Abfrageintervall von 1s angegeben, was aber nicht heißt, dass die Daten auch entsprechend schnell auf der Bridge vorliegen. Vielleicht hast Du ja hier praktische Erfahrungen.

[christiankratzer]

Du kannst gerne die bridge jede sekunde oder von mir aus 2 mal die sekunde abfragen. Es scheint immer der letzte Datensatz vor zu liegen.

Ich vermute aber Du wirst dann oefter kaputte Datensaetze bekommen die das polling tool dann verwerfen muss. Ich vermute dir bridge hat da stress.

Wenn Du zuverlaessig die Rohdaten willst solltest Du selbst ueber IR abfragen. Dann brauchst Du entweder eine IR bridge welche die Daten weiter zum Pulse kopiert oder Du holst Dir die Zugangsdaten aus der Pulse und schickst sie selber an amazon weiter.

[mdkeil]

Ich denke der zweite Punkt klingt interessant, in meinem Fall die Daten vom Hichi-USB-IR Kopf zu nutzen und diese dann selbst zu versenden.. da muss ich mich auf jede Fall mal einlesen.

[christiankratzer]

Das waere die eleganteste Loesung. Weiss natuerlich nicht wie Tibber dazu stehen wuerde.

[baiti]

Hallo,

erst einmal vielen Dank für das Projekt!

Ich nutze einige Monate recht problemlos die Variante mit einem Hichi-USB-IR Kopf in Verbindung mit einem parallelen TTL-Lesekopf, wo der Tibber-Pulse dran hängt. Bis letzten Freitag hat dies auch über einige Monate funktioniert-- Aktuell ließt der Pulse die Daten für max. eine Stunde stabil aus und scheint sich dann irgendwie aufzuhängen-- ich muss dann den Pulse neu positionieren dann geht es wieder.. habe bereits unterschiedliche Entfernungen/Positionen ausprobiert, ohne Erfolg.. Heute bekomme ich neue Lithium-Akkus, in der Hoffnung, dass es an der Spannungsversorgung liegt.. sollte dies auch nicht funktionieren, werde ich den Webzugang der Bridge freischalten und mir die Daten lokal holen..

Nun die entscheidende Frage: Ich benötige die Daten möglichst in der Aktualisierungsrate vom Zähler, die bei knapp 1s liegt-- liegen die Daten in der gleichen Geschwindigkeit auf der Bridge vor und können entsprechend sekündlich abgerufen werden?

Es wird ja ein minimales Abfrageintervall von 1s angegeben, was aber nicht heißt, dass die Daten auch entsprechend schnell auf der Bridge vorliegen. Vielleicht hast Du ja hier praktische Erfahrungen.

Bin gerade fieberhaft am ueberlegen, was das fuer ein use case das sein koennte, die Leistungswerte mit einer Frequenz von 1 Hz zu samplen? Koenntest du das grob erklaeren was da der Sinn ist? Es wuerde mir bei der Planung meines Systems helfen, wenn ich das verstehen wuerde.

[mdkeil]

Ganz einfach, aktuell lese ich meinen Zähler via Hichi-IR Kopf aus und schicke die Daten via MQTT Richtung VenusOS / Victron Batteriewechselrichter als "Grid Meter" --daher die Auflösung, da sonst die Anlage beim Ausregeln den Grid-Points zu träge ist.

[mdkeil]

@christiankratzer

Ich hatte irgendwo von Dir gelesen, das der Pulse jede Sekunde Daten an die Bridge sendet.. kann es sein, dass die Daten dann aggregiert werden?, denn via mqtt sendet die Bridge bei mir "nur" alle 3s ein raw-sml Datensatz an die Server.

[christiankratzer]

Der pulse, die bridge scheinen die sml daten roh weiter zu geben. Es findet so weit ich das ueberblicken kann lokal keinerlei Auswertung der daten statt. Die Auswertung scheint komplett in der AWS cloud zu passieren was auch Sinn macht.

Die bridge schickt also einfach jedes 3te sample roh per mqtt an AWS weiter.

Das mann beim pollen ueber die bridge manchmal kaputte datensaetze bekommt duerfte an einer ungeschickten implemtierung liegen.

[mdkeil]

Die bridge schickt also einfach jedes 3te sample roh per mqtt an AWS weiter.

Das deckt sich zumindest nicht mit meinen Beobachtungen, wenn ich mir im Webinterface der Bridge unter "Nodes" anschaue, wann die letzten Daten eingelaufen sind.. ist immer so zwischen 2 und 3s.. wie dem auch sei, die 1s / Datensatz wird man praktisch nicht erreichen können-- das macht mein Hichi IR-Kopf + vzlogger einfach besser..

[christiankratzer]

Ich habe zum spass mal meine polling rate auf 1 erhoeht und geschaut was ich an daten von der bridge bekomme. Es sind viele duplikate der sml transaction_id vorhanden.

"01fe1558" "01fe1558" "01fe155e" "01fe155e" "01fe155e" "01fe155e" "01fe156a" "01fe156a" "01fe156a" "01fe156a" "01fe1570" "01fe1570" "01fe1570" "01fe1570" "01fe157c" "01fe157c" "01fe157c" "01fe157c" "01fe1582" "01fe1582" "01fe1582" "01fe1582"

Da kann mann wirklich nur alle 10s von einem neuem Wert ausgehen.

[mdkeil]

Ich habe gerade gesehen.. im Web-UI unter Nodes kann man ja den Pulse noch umfangreich konfigurieren..

z.B. meter_throttle_ms steht auf 3000; und noch viel andere Punkte.. unter anderem ist dort auch das Senden der Metriken alle 5min hinterlegt.

[christiankratzer]

In der tibber app sieht mann die last ziemlich zeitnah. Also duerfte das mit den 3s durchaus hin kommen.

[mdkeil]

Ich werde auf jeden Fall nachher mal schauen, ob die Rate erhöht wird, wenn ich meter_throttle_ms reduziere.. erst mal unabhängig von eventuell negativen Seiteneffekten (höhere Fehlerrate, erhöhter Verbrauch, etc..) Sollte dies möglich sein, muss ich nur noch eine elegante Lösung in Node Red finden den via mqtt gesendeten raw-sml stream zu dekodieren, um an die relevanten Werte für mein virtuelles Gridmeter zu kommen, was ich für meine Victron-Speicher-Steuerung benötige. Dann nur noch den Pulse Batteriefrei machen und schon habe ich meine All-In-One-Lösung ohne viel Bastelei am Zähler.

[christiankratzer]

Wie das dekodieren in python geht siehst Du an dem code in diesem Projekt. Ich vermute aber tibber wird es auffallen falls dein Pulse oefter sendet als die anderen.

[mdkeil]

Also eine Reduzierung von meter_throttle_ms erhöht die Anzahl der Datenpunkte.. ich habe testweise auf 2000ms reduziert und der Pulse sendet ca. alle 2s einen Wert an die Bridge.. Es landet dann ca. alle 4s ein Datenpunkt in der App-Anzeige im Gegensatz zu alle 6s bei 3000ms meter_throttle_ms.. Bei 2000ms läuft der Pulse bei mir aber instabil und bricht relativ schnell den kompletten Datenversand ab.

[christiankratzer]

Wenn Du 1s daten brauchst musst Du selber mit eigenem IR probe pollen. Den pulse ausserhalb der specs zu Betreiben macht fuer mich keinen Sinn. Mir reichen daten alle 10s fuer mein eigenes monitoring.

[mdkeil]

Das mache ich ja aktuell auch.. baue bei mir nächste Woche aber noch ein wenig um.. der Pulse kommt dann auch aus dem Schaltschrank raus. Werde dann auch die lokale Bridge "zurückbauen".

[christiankratzer]

Der Pulse ist halt geschickt dass ich nicht monatlich den Stand fuer Tibber ablesen muss. Den dynamischen Stromtarif bekommt mann nur mit richtigem Smartmeter der selber meldet oder eben mit dem Pulse.

[mdkeil]

Mit raus aus dem Schaltschrank meine ich nur den örtlich Installationspunkt. 😜

[mdkeil]

Für mich ist die Frage beantwortet, daher schließe ich hier. Ich bin nun umgestiegen und schicke den raw-sml-stream nun selbst.

https://github.com/jsphuebner/esp-egycounter/issues/2#issuecomment-1785839199