Manche (wie ich) taten sich ja schwer, zum Tibber Pulse zu wechseln, weil es mit dem OBIS-Modul und z.B. einem IR-Lesekopf schon so sauber und stabil läuft. Für diese Nutzer habe ich jetzt den ersten Wurf einer Lösung fertig. Ich hoffe, dass Tibber diese Möglichkeit nicht "zu macht", ansonsten wird sie nämlich schön und ohne Cloud parallel zur "normalen" Tibber-Nutzung funktionieren.
Die Bridge des Tibber Pulse kann nämlich so konfiguriert werden, dass der initial nur zur Konfiguration verwendete Webserver in der Bridge dauerhaft an bleibt. Und hier lassen sich unter einer URL dann die jüngsten, binären SML-Daten des Lesekopfes auslesen. Das OBIS-Modul habe ich so angepasst, dass es nicht nur über "plain"-TCP oder einen Serial-Port abfragen kann, sondern auch per HTTP.
Folgende Schritte sind nötig:
Webserver auf Tibber-Bridge dauerhaft aktivieren- Das Passwort auf der Bridge notieren (steht beim QR-Code), z.B. ABCD-AA11
- Die Bridge rausziehen, vielleicht 1 Sekunde einstecken, wieder herausziehen und einstecken
- Nun sollte der Ring grün leuchten, wie am Anfang (nein, Ihr habt damit keine Settings verloren!)
- Am Laptop/Handy das WLAN "TibberBridge" suchen, WPA-Key ist das oben genannte Passwort
- Nach erfolgter Verbindung http://10.133.70.1/params/ (http://10.133.70.1/params/) aufrufen
- Username "admin", Passwort wie oben angeben
- Ganz unten das Attribut "webserver_force_enable" auf "true" setzen (eintippen!) und "Store params to flash"
- Nochmal aus und einstecken, jetzt sollte die Pulse-Bridge wieder "normal" hochkommen
Testen- Die IP der Pulse-Bridge im LAN identifizieren, "IP" im Folgenden
- Auf einer Kommandozeile testen:
curl -u admin:PASSWORT http://IP/data.json?node_id=1 | hexdump
Das Kommando sollte klappen, und im Hexdump etwas mit "1b1b1b1b" am Anfang erscheinen.
In FHEM aktivieren- define zaehlername OBIS http://IP/data.json?node_id=1
- Das Attribut "httpAuthorization" auf "admin:PASSWORT" setzen
- Das Attribut "pollingMode" auf "on", das Attribut "interval" z.B. auf 1 für sekündlich setzen
- Seite ggf. neu laden, Freude? Wenn nein, FHEM-Log kontrollieren und hier meckern.
Erst einmal checke ich das Modul noch NICHT ein, dafür ist es erst ein paar wenige Minuten alt, die Doku fehlt noch, ich hätte gerne 1-2 positive Rückmeldungen, u.s.w.
Daher bitte per Hand das u.a. Modul einspielen!Das Modul sollte ab morgen, 28.4., per Update verfügbar sein, bis dahin siehe Anhang.
Credits: https://blog.wyraz.de/allgemein/a-brief-analysis-of-the-tibber-pulse-bridge/ (https://blog.wyraz.de/allgemein/a-brief-analysis-of-the-tibber-pulse-bridge/) und an Sonicmaster, der mich darauf hinwies
Einrichtung hat nach der Beschreibung Super funktioniert. Ich Teste weite und berichte.
Funktioniert ohne Problem.
Vielen Dank!
Bei mir läuft es eigentlich auch sehr gut. Habe nur ein paar Logeinträge gefunden wo es immer mal wieder timeouts gibt.
Ich nutze allerdings aktuell beim Test 1 Sekunde fürs Polling.
2023.05.01 14:49:02 1: OBIS (Tibber_Pulse) - Error read from http://192.168.178.158:80 timed out
2023.05.01 14:49:04 1: OBIS (Tibber_Pulse) - Error connect to http://192.168.178.158:80 timed out
Bei mir läuft es auch. Ich wundere mich nur über die Formatierung von total_consumption und total_consumption, angezeigt wird beispielsweise "10441738.7", wohingegen der richtige Zählerstand "10441.738" beträgt.
Ja, die gängige Einheit sind Wh, nicht kWh bei SML. Oder es war halt im OBIS-Modul schon immer so :-)
Zitat von: gvzdus am 26 April 2023, 23:45:29Die Bridge des Tibber Pulse kann nämlich so konfiguriert werden, dass der initial nur zur Konfiguration verwendete Webserver in der Bridge dauerhaft an bleibt. Und hier lassen sich unter einer URL dann die jüngsten, binären SML-Daten des Lesekopfes auslesen. Das OBIS-Modul habe ich so angepasst, dass es nicht nur über "plain"-TCP oder einen Serial-Port abfragen kann, sondern auch per HTTP.
Folgende Schritte sind nötig:
Webserver auf Tibber-Bridge dauerhaft aktivieren
- Das Passwort auf der Bridge notieren (steht beim QR-Code), z.B. ABCD-AA11
- Die Bridge rausziehen, vielleicht 1 Sekunde einstecken, wieder herausziehen und einstecken
- Nun sollte der Ring grün leuchten, wie am Anfang (nein, Ihr habt damit keine Settings verloren!)
- Am Laptop/Handy das WLAN "TibberBridge" suchen, WPA-Key ist das oben genannte Passwort
- Nach erfolgter Verbindung http://10.133.70.1/params/ (http://10.133.70.1/params/) aufrufen
- Username "admin", Passwort wie oben angeben
- Ganz unten das Attribut "webserver_force_enable" auf "true" setzen (eintippen!) und "Store params to flash"
- Nochmal aus und einstecken, jetzt sollte die Pulse-Bridge wieder "normal" hochkommen
Testen
- Die IP der Pulse-Bridge im LAN identifizieren, "IP" im Folgenden
- Auf einer Kommandozeile testen:
curl -u admin:PASSWORT http://IP/data.json?node_id=1 | hexdump
Das Kommando sollte klappen, und im Hexdump etwas mit "1b1b1b1b" am Anfang erscheinen.
Danke für die Beschreibung! Das Auslesen der binären SML-Daten hat gut geklappt!
Jetzt wird es evtl etwas offtopic: ich nutze kein FHEM sondern NodeRed - kennt jmd eine Möglichkeit die Daten dort auszulesen? Evtl helfen mir schon die Sourcen des FHEM OBIS Moduls?
EDIT: als Alternative habe ich jetzt https://github.com/micw/tibber-pulse-reader#running--docker am Laufen und lasse mir die Daten als MQTT-Nachricht schicken. Das scheint erstmal ganz gut zu funktionieren ...
Danke und VG
Micha
Vielen Dank für das OBIS SML Modul. Es klappt soweit ganz gut, allerdings:
Im Log taucht bei mir sehr häufig "2nd TL-byte != 0, reserved according spec". Bin ich der Einzige damit?
Es wird sehr wahrscheinlich an Deinem Zähler und weniger wahrscheinlich am Pulse liegen.
Ok, ich kann also mit halbwegs gutem Gewissen "attr Stromzaehler verbose 2" setzen? Sollte man an dem CRC Error noch was machen, oder ist das egal?
Die mir wichtigsten Werte "total_consumption", "total_feed" und "power" sind vorhanden, der Rest sieht hier so aus:
Internals:
CFGFN
CRC_Errors 6
DEF http://TIBBER_IP/data.json?node_id=1
DeviceName http://TIBBER_IP/data.json?node_id=1
FUUID 123...5678
MeterType SML
NAME Stromzaehler
NEXT 2023-05-05 18:39:00
NR 591
STATE -5 W
TYPE OBIS
eventCount 184
READINGS:
2023-05-05 18:38:00 1.0.0.2.0.0 1.03
2023-05-05 18:38:00 1.0.14.7.0.255 49.9 Hz
2023-05-05 18:38:00 1.0.81.7.1.255 123 var
2023-05-05 18:38:00 1.0.81.7.15.255 189 var
2023-05-05 18:38:00 1.0.81.7.2.255 242 var
2023-05-05 18:38:00 1.0.81.7.26.255 352 var
2023-05-05 18:38:00 1.0.81.7.4.255 210 var
2023-05-05 18:38:00 1.0.96.1.0.255 ABCDE
2023-05-05 18:38:00 1.0.96.90.2.1 ABCD
2023-05-05 18:38:00 ManufID2 P1.01.02
2023-05-05 18:38:00 current_L1 1.56 A
2023-05-05 18:38:00 current_L2 1.52 A
2023-05-05 18:38:00 current_L3 1.6 A
2023-05-05 18:38:00 power -5 W
2023-05-05 18:38:00 power_L1 -299 W
2023-05-05 18:38:00 power_L2 -345 W
2023-05-05 18:38:00 power_L3 638 W
2023-05-05 18:38:00 total_consumption 333543.6 Wh
2023-05-05 18:38:00 total_feed 1542369.9 Wh
2023-05-05 18:38:00 voltage_L1 229.8 V
2023-05-05 18:38:00 voltage_L2 230.8 V
2023-05-05 18:38:00 voltage_L3 229 V
helper:
BUFFER
DIRECTIONSUM <
EoM 1
HTTPAUTH Authorization: Basic BLABLABLA
LASTDATA ...BINÄRE DATEN...
LastPacketTime 1683304680.16297
NETDEV 0
SPEED 5
TRIGGERTIME 1683304740
Channels:
DEVICES:
60
RULECACHE:
1-0:0.2.0*0 unknown
1-0:1.8.0*255 Counter
1-0:14.7.0*255 Channels
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:31.7.0*255 Channels
1-0:32.7.0*255 Channels
1-0:36.7.0*255 Channels
1-0:51.7.0*255 Channels
1-0:52.7.0*255 Channels
1-0:56.7.0*255 Channels
1-0:71.7.0*255 Channels
1-0:72.7.0*255 Channels
1-0:76.7.0*255 Channels
1-0:81.7.1*255 Channels
1-0:81.7.15*255 Channels
1-0:81.7.2*255 Channels
1-0:81.7.26*255 Channels
1-0:81.7.4*255 Channels
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
1-0:96.50.1*4 ManufID2
1-0:96.90.2*1 unknown
1-0:97.97.0*0 unknown
255-255:255.255.255*255 unknown
directions:
Attributes:
alignTime 00:00
event-on-change-reading .*
group Strom
httpAuthorization admin:BLABLABLA
interval 60
pollingMode on
stateFormat power
unitReadings on
verbose 2
Mir fallen auch viele CRC-Fehler auf, seit ich nicht mehr "OBIS-IR-Lesekopf direkt", sondern den Pulse auswerte. Ich bin nach 8 Tagen auf 577 CRC-Fehlern: Das entspricht etwa 0,1% der gelesenen Pakete. Ich vermute, dass da einfach die Hardware Schönheitsfehler hat, z.B. mal ein Byte verliert. Da die Fehler aber mit 1:65536 Wahrscheinlichkeit erkannt werden (und im Zufallsfall vermutlich das Paket trotzdem nicht ausgewertet werden würde), mache ich mir deswegen keine Gedanken.
Loglevel 2 kannst Du problemlos setzen. Übrigens sehr verbose, Dein Zähler :-).
Topp, danke!
Ich habe mir noch einige UserReadings dazu erstellt (noch in Erprobung):
Leistung_Stromnetz_Mittelwert:power.* { ## Bezug/Einspeisung in das Netz
sprintf("%.1f", movingAverageT("$NAME", "power", 600));
},
ImportZaehler:total_consumption.* {
round(ReadingsNum($NAME, "total_consumption", 0) / 1000, 0);
},
Energie_Import_heute {
ReadingsNum($NAME, "total_consumption", 0) - ReadingsNum($NAME, "offset_import", 0);
},
Energie_Import_gestern {
my $LastUpdateDay = strftime("%d", localtime(time_str2num(ReadingsTimestamp($NAME, "Energie_Import_gestern", undef))));
my $NowDay = strftime("%d", localtime());
if ($LastUpdateDay ne $NowDay) {
return ReadingsNum($NAME, "Energie_Import_heute", 0);
}
return;
},
ExportZaehler:total_feed.* {
round(ReadingsNum($NAME, "total_feed", 0) / 1000, 0);
},
Energie_Export_heute {
ReadingsNum($NAME, "total_feed", 0) - ReadingsNum($NAME, "offset_export", 0);
},
Energie_Export_gestern {
my $LastUpdateDay = strftime("%d", localtime(time_str2num(ReadingsTimestamp($NAME, "Energie_Export_gestern", undef))));
my $NowDay = strftime("%d", localtime());
if ($LastUpdateDay ne $NowDay) {
return ReadingsNum($NAME, "Energie_Export_heute", 0);
}
return;
},
offset_export {
my $LastUpdateDay = strftime("%d", localtime(time_str2num(ReadingsTimestamp($NAME, "offset_export", undef))));
my $NowDay = strftime("%d", localtime());
if ($LastUpdateDay ne $NowDay) {
return ReadingsNum("$name", "total_feed", undef);
}
return;
},
offset_import {
my $LastUpdateDay = strftime("%d", localtime(time_str2num(ReadingsTimestamp($NAME, "offset_import", undef))));
my $NowDay = strftime("%d", localtime());
if ($LastUpdateDay ne $NowDay) {
return ReadingsNum("$name", "total_consumption", undef);
}
return;
}
Ich warte jetzt auf Mitternacht um morgen dann zu schauen, ob das auch so korrekt mit dem Werten zum Tageswechsel übernommen wird.
Gerade in 5 min Pulse + fhem eingerichtet...einfach nur super.
@gvzdus Herzlichen Dank für das Modul.
Hallo zusammen,
ich würde auch gerne den Tibber Pulse mit FHEM verwenden. Ich habe diesen so eingerichtet, dass die Tibber Bridge die vom IR-Kopf gelesenen Werte an meinen eigenen MQTT-Server (in diesem Fall MQTT2-Server in FHEM) überträgt. Damit erhalte ich aber als Message Body die SML-Nachricht im HEX-Format. Nun würde ich die Nachricht gerne vom OBIS v2 Modul verarbeiten lassen. Bisher habe ich aber keine Idee, wie ich das anstellen könnte. Gibt es vielleicht schon eine eingebaute Möglichkeit, dass OBIS v2 auf die MQTT-Nachrichten reagiert und diese auswertet? Oder müsste die notwendige Funktionalität erst noch eingebaut werden? Oder gibt es vielleicht einen Umweg?
Aktuell gehe ich den Umweg über das schon genannte Projekt https://github.com/micw/tibber-pulse-reader#running--docker. Wenn OBIS v2 das direkt könnte, würde der zusätzliche Docker-Container wieder wegfallen.
Mir fehlt leider aktuell die Zeit, mich selbst reinzuarbeiten. Ich wüsste auch gar nicht, wo ich ansetzen müsste, eher in OBIS v2 oder vielleicht sogar an anderer Stelle in FHEM, vielleicht DevIO?
Danke auf jeden Fall für die bisherige Umsetzung für den Tibber Pulse und ich würde mich über Ideen und/oder sogar die Umsetzung freuen.
Zitat von: dennisk am 30 Mai 2023, 18:18:12Hallo zusammen,
ich würde auch gerne den Tibber Pulse mit FHEM verwenden. Ich habe diesen so eingerichtet, dass die Tibber Bridge die vom IR-Kopf gelesenen Werte an meinen eigenen MQTT-Server (in diesem Fall MQTT2-Server in FHEM) überträgt. Damit erhalte ich aber als Message Body die SML-Nachricht im HEX-Format. Nun würde ich die Nachricht gerne vom OBIS v2 Modul verarbeiten lassen. Bisher habe ich aber keine Idee, wie ich das anstellen könnte. Gibt es vielleicht schon eine eingebaute Möglichkeit, dass OBIS v2 auf die MQTT-Nachrichten reagiert und diese auswertet? Oder müsste die notwendige Funktionalität erst noch eingebaut werden? Oder gibt es vielleicht einen Umweg?
Aktuell gehe ich den Umweg über das schon genannte Projekt https://github.com/micw/tibber-pulse-reader#running--docker. Wenn OBIS v2 das direkt könnte, würde der zusätzliche Docker-Container wieder wegfallen.
Mir fehlt leider aktuell die Zeit, mich selbst reinzuarbeiten. Ich wüsste auch gar nicht, wo ich ansetzen müsste, eher in OBIS v2 oder vielleicht sogar an anderer Stelle in FHEM, vielleicht DevIO?
Danke auf jeden Fall für die bisherige Umsetzung für den Tibber Pulse und ich würde mich über Ideen und/oder sogar die Umsetzung freuen.
Hallo ich habe noch nicht ganz verstanden, warum du den Weg von der Tibber Bridge über MQTT nach FHEM eingeschlagen hast und es nicht so machst wie in diesem Beitrag #1 geschrieben. Lokal auslesen und direkt im OBIS Modul die Tibber Bridge einstellen. Dann hast du doch das was du willst oder?
Verstehe ich auch so: Vermutlich ist ja die Tibber Bridge bei ihm (Dir) schon auf "Dauer-HTTP-Server" eingestellt. Also einfach beim 2. Block aus Beitrag #1 weitermachen - dem Test - und fertig.
Irgendein Zusatzmodul im Docker-Container brauchst Du nicht, das macht das OBIS-Modul gleich mit.
Hallo @xerion,@gvzdus,
danke für eure Rückmeldungen. Ihr habt natürlich recht, es geht auch mittels des vorgeschlagenen Pollings. Mich stört daran nur, dass das eigentlich für diese Zwecke vorgesehene Messaging-Protokoll MQTT dann nicht verwendet wird und ich den Tibber noch zusätzlich mit einem Polling belaste. Theoretisch ließe sich der Webserver auf dem verbauten ESP32 dann auch wieder abschalten bzw. wieder so einstellen, dass er eben nur gestartet wird, wenn die Tibber Bridge im AP-Modus hochfährt. Und ich könnte mir vorstellen, dass der Use Case auch für die diversen ESP-Selbstbau-Leseköpfe mit Tasmota eine Alternative sein könnte, d.h. ich kann die SML-Auswertung dem OBIS-Modul überlassen und benötige kein entsprechendes Skript mehr für die Tasmota-basierte Auswertung. Ich hoffe, das macht es ein wenig klarer?
Ja, jetzt verstanden :-)
Du hast also die Variante "MQTT-Proxy-Server" gewählt, und lässt die Bridge den MQTT-Stream nicht direkt in die AWS schicken, sondern über einen lokalen Proxy? Bei der Möglichkeit hätte ich persönlich als Tibber viel mehr dagegen als gegen einen HTTP-Server, weil es die Option zur Datenmanipulation quasi vorbereitet. Aber sei es drum.
Ich habe mal schnell was gebastelt (siehe Anhang), dass Du mit "set <obisdevice> data <sml in hex>" Daten einfüttern kannst. Anbei die Variante. Also:
defmod ot OBIS none
und dann jeweils Hex so einkippen:
set ot OBIS data 1b1b1b1b....1b1b1b1b1a.....
Hilft das? Wie sehen denn die MQTT-Nachrichten aus? Hex oder Binär?
P.S. Kann sein, dass ich mich jetzt völlig verhaue mit der Sichtbarkeit von Modul-Funktionen außerhalb ("Perl-Basics"). ABER:
Du musst eigentlich nur OBIS_Parse mit Hash und den binären Inputdaten aufrufen, dann wird geparsed und in das Device dekodiert. Also nehmen wir mein Beispiel mit einem OBIS-Device "ot". Dann solltest Du in einem Notify, dass auf ein MQTT-Topic triggert, so etwas schreiben können (auch mit dem bestehenden Modul):
define smlprocess notify <MQTT-Device>:<smltopic> { OBIS_Parse (%defs{"ot"}, $EVTPART1) }
oder - bei HEX -
define smlprocess notify <MQTT-Device>:<smltopic> { OBIS_Parse (%defs{"ot"}, (pack 'H*', $EVTPART1) ) }
Vielleicht einen Versuch wert - hier aber ungetestet.
Zitat von: gvzdus am 01 Juni 2023, 22:20:47P.S. Kann sein, dass ich mich jetzt völlig verhaue mit der Sichtbarkeit von Modul-Funktionen außerhalb ("Perl-Basics"). ABER:
Vielen Dank für den Vorschlag, hab ich ausprobiert:
defmod obis OBIS none
defmod obis_smlprocess notify MQTT2_TIBBERPULSE:SML:.* { OBIS_Parse (%defs{"obis"}, (pack 'H*', $EVENT) ) }
Hinter SML musste ich noch
:.*
ergänzen, sonst hat das notify erst gar nicht ausgelöst. Leider erhalte ich damit aber keine Readings im OBIS device, sondern diesen Fehler:
PERL WARNING: %defs{"obis"} in scalar context better written as $defs{"obis"} at (eval 1540542) line 1.
2023.06.02 17:31:04 3: eval: my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $EVTPART1= $evalSpecials->{'%EVTPART1'};my $EVTPART10= $evalSpecials->{'%EVTPART10'};my $EVTPART11= $evalSpecials->{'%EVTPART11'};my $EVTPART12= $evalSpecials->{'%EVTPART12'};my $EVTPART13= $evalSpecials->{'%EVTPART13'};my $EVTPART14= $evalSpecials->{'%EVTPART14'};my $EVTPART15= $evalSpecials->{'%EVTPART15'};my $EVTPART16= $evalSpecials->{'%EVTPART16'};my $EVTPART17= $evalSpecials->{'%EVTPART17'};my $EVTPART18= $evalSpecials->{'%EVTPART18'};my $EVTPART19= $evalSpecials->{'%EVTPART19'};my $EVTPART2= $evalSpecials->{'%EVTPART2'};my $EVTPART20= $evalSpecials->{'%EVTPART20'};my $EVTPART3= $evalSpecials->{'%EVTPART3'};my $EVTPART4= $evalSpecials->{'%EVTPART4'};my $EVTPART5= $evalSpecials->{'%EVTPART5'};my $EVTPART6= $evalSpecials->{'%EVTPART6'};my $EVTPART7= $evalSpecials->{'%EVTPART7'};my $EVTPART8= $evalSpecials->{'%EVTPART8'};my $EVTPART9= $evalSpecials->{'%EVTPART9'};my $NAME= $evalSpecials->{'%NAME'};my $SELF= $evalSpecials->{'%SELF'};my $TYPE= $evalSpecials->{'%TYPE'};{ OBIS_Parse (%defs{"obis"}, (pack 'H*', $EVENT) ) }
Wenn ich das Prozentzeichen durch ein Dollar-Zeichen ersetze, dann erhalte ich nur diese Ausgabe:
2023.06.02 17:31:04 3: obis_smlprocess return value: obis
Hab ich für diesen Ansatz noch irgendwas vergessen oder falsch gemacht, oder hängt es tatsächlich mit der Sichtbarkeit der Methode OBIS_Parse, d.h. aus dem notify heraus kann diese gar nicht aufgerufen werden?
Deinen ersten Vorschlag mit der angehängten angepassten Modul-Datei konnte ich noch nicht testen.
Zitat von: dennisk am 03 Juni 2023, 10:48:46Deinen ersten Vorschlag mit der angehängten angepassten Modul-Datei konnte ich noch nicht testen.
Jetzt konnte ich auch diesen Ansatz testen. Funktioniert soweit! Vielen Dank auf jeden Fall! Könntest Du Dir vorstellen, das vielleicht ins Modul aufzunehmen, ggf. auch weiter überarbeitet - war ja erstmal nur der schnelle Wurf. Ich teste auch gerne, wenn ich bestimmte Dinge ausprobieren soll.
Moin, ein Denkfehler von mir beim "Perl trocken schreiben":
Es muss $defs{"obis"}
heißen, nicht %defs{"obis"}
.
Aber das hast Du ja getestet. Wie kommen die MQTT-Daten denn jetzt an? HEX oder Binär? Welche Variante musstest Du mit dem angepassten Modul nehmen?
Zitat von: gvzdus am 04 Juni 2023, 11:31:37Aber das hast Du ja getestet. Wie kommen die MQTT-Daten denn jetzt an? HEX oder Binär? Welche Variante musstest Du mit dem angepassten Modul nehmen?
Sorry, die Frage hatte ich überlesen. Die Daten kommen vom Tibber wohl binär. Bevor diese dann in ein entsprechendes Reading des MQTT2-Devices geschrieben werden, wandle ich diese in Hex um:
tibber-pulse/sml:.* { return {SML=>join(' ', unpack("(H2)*", $EVENT))} }
Ich habe seit gestern Probleme die Daten Lokal auszulesen. Webserver ist noch erreichbar aber es können keine Daten ausgewertet werden:
2023.06.08 00:17:44 1: OBIS (Tibber_Pulse) - Error connect to http://192.168.178.158:80 timed out
Hat sonst noch jemand Probleme?
Zitat von: xerion am 08 Juni 2023, 12:25:45Ich habe seit gestern Probleme die Daten Lokal auszulesen. Webserver ist noch erreichbar aber es können keine Daten ausgewertet werden:
2023.06.08 00:17:44 1: OBIS (Tibber_Pulse) - Error connect to http://192.168.178.158:80 timed out
Hat sonst noch jemand Probleme?
Hat sich schon erledigt. Ist doch nicht immer die Software der Übeltäter. Wenn der Kleber vom Pulse nicht hält und dann herunterfällt dann kann ja auch nichts gelesen werden. :'(
Zitat von: dennisk am 04 Juni 2023, 11:13:30Könntest Du Dir vorstellen, das vielleicht ins Modul aufzunehmen, ggf. auch weiter überarbeitet - war ja erstmal nur der schnelle Wurf. Ich teste auch gerne, wenn ich bestimmte Dinge ausprobieren soll.
Mal als Zwischenstand: Bisher läuft das Ganze sehr zuverlässig. Wäre wirklich klasse, wenn diese Möglichkeit so oder ähnlich ins Modul aufgenommen werden könnte.
Zitat von: dennisk am 08 Juni 2023, 23:52:50Mal als Zwischenstand: Bisher läuft das Ganze sehr zuverlässig. Wäre wirklich klasse, wenn diese Möglichkeit so oder ähnlich ins Modul aufgenommen werden könnte.
@gvzdus Könntest Du Dir vorstellen, das aufzunehmen? Es funktioniert wie gesagt schon einige Zeit ohne Probleme. Ich wäre Dir jedenfalls sehr dankbar!
Moin, ist morgen im offiziellen Tree drin. Keine Änderungen ggü. der Version oben.
Super, herzlichen Dank für die pragmatische Unterstützung!
Hallo,
herzlichen Dank für die Beschreibung
Ich habs versucht nach Anleitung, bekomme aber vom beim curl kein 1B1B sondern:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 18 100 18 0 0 165 0 --:--:-- --:--:-- --:--:-- 168
0000000 6142 2064 6572 7571 7365 2074 7973 746e
0000010 7861
0000012
Webserver kann ich auch über die von der Fritzbox statisch verwendete ip ansprechen, auf den pulse Webserver zugreifen (und da steht der auch auf "true")
in fhem gibts das device, aber da tut sich halt nix
Wie finde ich den Fehler?
Ein update hab ich gemacht
Herzlichen Dank, Harald
Hallo,
nach einigem rumprobieren hat sich gezeigt, das der IR-Kopf noch nicht mit dem Gateway verbunden war.
Jetzt klappts. (bekomme beim curl aber immer noch was anderes)
Herzlichen Dank für das geniale Modul, konnte damit nahtlos meinen IR-Lesekopf ersetzen, da die readings gleich heißen!
Gruß, Harald
P.S. Jetzt fehlt noch das Abholen der Preisinfo...
Ich wollte mich nur kurz bedanken für die Bereitstellung dieser Lösung und für die gute Beschreibung auf der 1. Seite :-)
Gruß
Blueberry63
Hallo zusammen,
erstmal herzlichen Dank für diese tolle Lösung!
Ich habe die Anleitung 1:1 aus dem ersten Post umgesetzt, nur leider bekommt er keine Verbindung und ich weiß nicht warum, hat jemand eine Idee?
Der Webserver ist auf true gesetzt, das Device in FHEM habe ich mehrfach neu angelegt.
Im Log bekomme ich die Meldung, dass er nicht errechbar ist. Die IP Adresse ist korrekt.
2023.11.13 12:23:10 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:13 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:16 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:19 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:22 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:25 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:28 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:31 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:34 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:37 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:40 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:43 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:46 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
Wenn ich die URL im Browser mit Benutzer Passwort öffne, bekomme ich die gleiche Rückmeldung, die auch unter Nodes/Data auf der Bridge angezeigt werden.
Curl gibt mir die 1b1b1 Blöcke zurück, also auch gut. Nur FHEM möchte irgendwie nicht :'(
Viele Grüße
Zitat von: gvzdus am 08 Juli 2023, 12:03:45Moin, ist morgen im offiziellen Tree drin. Keine Änderungen ggü. der Version oben.
Hallo nochmal, mir ist noch eine Warnung aufgefallen, die beim Initialisieren des Device bzw. beim Neustart von FHEM auftritt:
PERL WARNING: Use of uninitialized value in string eq at /usr/share/fhem/FHEM/47_OBIS.pm line 643.
Wenn ich Deine Anpassung für meinen Use Case richtig verstanden habe, dann wird ja gar kein OBIS Device angelegt. Dann ist das Auftreten der Warnung an der Stelle aus meiner Sicht, ohne tiefgehende Code-Kenntnis nachvollziehbar. Als pragmatischen Versuch, die Warnung zu vermeiden, habe ich erfolgreich folgende Anpassung vorgenommen:
Aus Zeile &43:
$hash->{helper}{EoM}+=1 if ($hash->{helper}{DEVICES}[1]>0);
wird:
$hash->{helper}{EoM}+=1 if ($hash->{helper}{DEVICES}[1]>0 // '');
Ist das eine adäquate Lösung? Seiteneffekte sind mir bisher noch nicht aufgefallen, konnte aber natürlich auch nicht testen, wie sich das Modul verhält, wenn tatsächlich ein Device existiert. Könntest Du die Änderung so oder ggf. korrigiert in den Code übernehmen?
Vielen Dank schon mal und beste Grüße
Hallo,
welche Werte können denn so praktisch aus der Pulse-Bridge ausgelesen und in FHEM weiter verarbeitet werden?
Ich bin ab 1.1.24 bei tibber und brauche letztlich ein gleiches Konstrukt. Wir haben eine sog. Kaskadenschaltung im Sicherungskasten.
Zähler 1 macht den Gesamtstrom am Übergabepunkt inkl. Einspeisung.
Zähler 2 ist der Haushaltsstrom.
So wie es eben in Kaskade geschaltet ist, ist Z1 minus Z2 die Wärmepumpe und eben Z2 der Haushaltsstrom. Und jeweils 2.8.0 zeigt z.B. den Eigenverbrauch der PV-Anlage für HH-Strom als Z2 2.8 und Einspeisung an Z1 2.8.0 an. Somit z.B. Z1 2.8.0 minus Z2 2.8.0 = Eigenverbrauch PV für WP.an.
Am Zähler 2 kommt nun der pulse an dem aber auch schon ein UWE-IR Sensor hängt. Am Zähler 1 hängt auch ein IR Sensor.
Ich lese also jeweils die Werte 1.8.0 und 2.8.0 und habe mir ein komplexes reading gebaut.
Alles über das OBIS Modul im FHEM mit hunderten von readings und Berechnungen abgebildet.
Das möchte ich nicht aufgeben.
Wie bekomme ich also am Zähler 2 die Werte des bisherigen IR-Lesekopf und den Pulse im Fhem übertragen. Was kommt also im OBIS Modul an Werten a?
Danke für die Infos.
Jörg
Hallo Jörg,
die Daten werden von der Tibber-Bridge auch im SML-Format zur Verfügung gestellt. Wenn Du es geschafft hast, die Bridge auf
webserver_force_enable" = "true"
zu stellen, musst Du nur im aktuellen Device die DEF ändern:
http://192.168.xx.xx/data.json?node_id=1
Gruß
Blueberry63
Bei mir hat es nun auch geklappt. Die Bridge liefert total_consumption und total feed wie ich es mir erhofft habe.
Große Sorge hatte ich, wie ich damit umgehen, dass ich seit Jahren 2 HICHI IR Leseköpfe betreiben, die an meinen 2 Zählern hängen und die Werte jeweils nicht nur ablesen, sondern dann über komplexe readings weiter verarbeiten. Ich betreibe 2 Zähler im Messkonzept 8 (Kaskadenschaltung) mit zusätzlicher PV Anlage und Wallbox. Da ist bei den userreadings ganz ordentlich was zu rechnen und dann u.a. für das Dashboard darzustellen.
Aber auch das ist besser geworden, als zuerst gedacht.
Letztlich habe ich die Definition des Haushaltszähler von dem DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller.... einfach nur auf http://192.168.2.xxx/data.json?node_id=1 umgestellt. Admin:Pw dazu und schon kamen die Werte exakt wie vorher.
Danke also für die vielen Infos und Bereitstellung des OBIS Moduls.
Hallo zusammen,
gibt es die Möglichkeit den SML Parse zu beeinflussen? Bei meinem DZG Zähler erhalte ich über Obis falsche Werte bei Einspeisung (keine neg. Werte).
Entweder ist es das Problem mit dem Überlauf oder etwas anderes.
Jedenfalls bekomme ich in der Tibber App und über z.B.
https://github.com/micw/tibber-pulse-reader
die richtigen negativen Werte angezeigt.
Damals bei meinem Tasmota lief es auch, am Zähler ansich kann es also nicht liegen.
Oder muss ich deoch über eine andere Schnittstelle gehen und die Daten über MQTT an Fhem übermitteln?
Danke,
Gruß
Zitathler erhalte ich über Obis falsche Werte bei Einspeisung (keine neg. Werte).
Kannst Du den Wert nicht einfach negieren und in ein Userreading schreiben?
Vermutlich hast Du einen neueren DZG-Zähler. Die älteren Zähler hatten einen Kodierungsbug, für den ein Workaround im Modul ist.
Wenn Du das Attribut "nohacks" auf 1 setzt (FHEM nicht älter als 1-2 Monate, sonst updaten), wird es vermutlich funktionieren.
vielen Dank für eure schnellen Antworten, den Parameter "nohacks" hatte ich dann auch gesehen.
jetzt muss es nur noch Sonne geben, damit ich sehen kann ob es das auch schon war ;-)
Hi zusammen, ich brauche mal hilfe, da ich es nicht zum laufen bekomme. Bridge ist eingerichtet und auch erreichbar. Definiere ich das device, wie oben angegeben, erhalte ich folgendes im Log:
2023.12.29 16:26:41 5: OBIS (TibberPulse) - Internal timer set to 2023-12-29 16:26:46
2023.12.29 16:26:41 5: OBIS (TibberPulse) - Got data, len 848
2023.12.29 16:26:41 4: OBIS (TibberPulse) - HTTP data unchanged
2023.12.29 16:26:46 5: OBIS (TibberPulse) - Internal timer set to 2023-12-29 16:26:51
2023.12.29 16:26:46 5: OBIS (TibberPulse) - Got data, len 848
2023.12.29 16:26:51 5: OBIS (TibberPulse) - Internal timer set to 2023-12-29 16:26:56
2023.12.29 16:26:51 5: OBIS (TibberPulse) - Got data, len 848
2023.12.29 16:26:51 4: OBIS (TibberPulse) - HTTP data unchanged
RAW Definition mit Internals zeigt dies (FHEM scheint also was zu empfangen - ich sehe nur nix im Device)
defmod TibberPulse OBIS http://192.168.178.179/data.json?node_id=1
attr TibberPulse httpAuthorization admin:******
attr TibberPulse interval 5
attr TibberPulse pollingMode on
attr TibberPulse room 80_Vorratskeller
attr TibberPulse verbose 5
# CFGFN
# DEF http://192.168.178.179/data.json?node_id=1
# DeviceName http://192.168.178.179/data.json?node_id=1
# FUUID 658ee485-f33f-00c5-7ede-28e62bcdbde2a3ee
# MeterType SML
# NAME TibberPulse
# NR 243
# STATE ???
# TYPE OBIS
# helper:
# BUFFER 44*kWh)
#1-0:16.7.0*255(000518*W)
#1-0:32.7.0*255(236.2*V)
#1-0:52.7.0*255(235.5*V)
#1-0:72.7.0*255(236.2*V)
#1-0:31.7.0*255(000.82*A)
#1-0:51.7.0*255(000.37*A)
#1-0:71.7.0*255(001.62*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(346*deg)
#1-0:81.7.15*255(002*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000153*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000301*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃=/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA**********)
#1-0:1.8.0*255(001263.6748*kWh)
#1-0:1.8.1*255(001263.6748*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000517*W)
#1-0:32.7.0*255(236.2*V)
#1-0:52.7.0*255(235.6*V)
#1-0:72.7.0*255(236.2*V)
#1-0:31.7.0*255(000.81*A)
#1-0:51.7.0*255(000.37*A)
#1-0:71.7.0*255(001.62*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(347*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(340*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000159*W)
#1-0:56.7.0*255(000060*W)
#1-0:76.7.0*255(000305*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃0/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA********)
#1-0:1.8.0*255(001263.6789*kWh)
#1-0:1.8.1*255(001263.6789*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000523*W)
#1-0:32.7.0*255(236.2*V)
#1-0:52.7.0*255(235.6*V)
#1-0:72.7.0*255(236.1*V)
#1-0:31.7.0*255(000.81*A)
#1-0:51.7.0*255(000.37*A)
#1-0:71.7.0*255(001.71*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(348*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000156*W)
#1-0:56.7.0*255(000060*W)
#1-0:76.7.0*255(000302*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃?/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6802*kWh)
#1-0:1.8.1*255(001263.6802*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000516*W)
#1-0:32.7.0*255(236.2*V)
#1-0:52.7.0*255(235.6*V)
#1-0:72.7.0*255(236.1*V)
#1-0:31.7.0*255(000.81*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.67*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(347*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000153*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000301*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃7/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6844*kWh)
#1-0:1.8.1*255(001263.6844*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000561*W)
#1-0:32.7.0*255(236.1*V)
#1-0:52.7.0*255(235.5*V)
#1-0:72.7.0*255(236.1*V)
#1-0:31.7.0*255(001.06*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.59*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(347*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000196*W)
#1-0:56.7.0*255(000060*W)
#1-0:76.7.0*255(000302*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃?/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6857*kWh)
#1-0:1.8.1*255(001263.6857*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000522*W)
#1-0:32.7.0*255(236.1*V)
#1-0:52.7.0*255(235.4*V)
#1-0:72.7.0*255(236.1*V)
#1-0:31.7.0*255(000.77*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.63*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(342*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000154*W)
#1-0:56.7.0*255(000062*W)
#1-0:76.7.0*255(000304*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃8/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6898*kWh)
#1-0:1.8.1*255(001263.6898*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000537*W)
#1-0:32.7.0*255(236.3*V)
#1-0:52.7.0*255(235.5*V)
#1-0:72.7.0*255(236.0*V)
#1-0:31.7.0*255(000.81*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.59*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(344*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(338*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000156*W)
#1-0:56.7.0*255(000062*W)
#1-0:76.7.0*255(000303*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃</ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6911*kWh)
#1-0:1.8.1*255(001263.6911*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000516*W)
#1-0:32.7.0*255(236.3*V)
#1-0:52.7.0*255(235.3*V)
#1-0:72.7.0*255(236.0*V)
#1-0:31.7.0*255(000.80*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.58*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(347*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000155*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000296*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃6/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6953*kWh)
#1-0:1.8.1*255(001263.6953*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000518*W)
#1-0:32.7.0*255(236.4*V)
#1-0:52.7.0*255(235.6*V)
#1-0:72.7.0*255(236.3*V)
#1-0:31.7.0*255(000.81*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.57*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(345*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000161*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000303*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃?/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.6966*kWh)
#1-0:1.8.1*255(001263.6966*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000515*W)
#1-0:32.7.0*255(236.2*V)
#1-0:52.7.0*255(235.5*V)
#1-0:72.7.0*255(236.2*V)
#1-0:31.7.0*255(000.85*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.61*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(346*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000154*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000312*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.6*kWh)
#!
#␃2/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.7007*kWh)
#1-0:1.8.1*255(001263.7007*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000526*W)
#1-0:32.7.0*255(236.3*V)
#1-0:52.7.0*255(235.5*V)
#1-0:72.7.0*255(236.3*V)
#1-0:31.7.0*255(000.81*A)
#1-0:51.7.0*255(000.37*A)
#1-0:71.7.0*255(001.62*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(347*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(339*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000155*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000301*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.7*kWh)
#!
#␃7/ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.7020*kWh)
#1-0:1.8.1*255(001263.7020*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000512*W)
#1-0:32.7.0*255(236.3*V)
#1-0:52.7.0*255(235.4*V)
#1-0:72.7.0*255(236.3*V)
#1-0:31.7.0*255(000.85*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.59*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(345*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(338*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000155*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000297*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.7*kWh)
#!
#␃1
# Channels
# EoM -1
# HTTPAUTH Authorization: Basic YWRtaW46QzdNRi1CRjkw
#
# LASTDATA /ZPA5GH305.v2-01.00-G
#
#␂1-0:C.1.0*255(1ZPA*******)
#1-0:1.8.0*255(001263.7020*kWh)
#1-0:1.8.1*255(001263.7020*kWh)
#1-0:1.8.2*255(000000.0000*kWh)
#1-0:2.8.0*255(006460.9144*kWh)
#1-0:16.7.0*255(000512*W)
#1-0:32.7.0*255(236.3*V)
#1-0:52.7.0*255(235.4*V)
#1-0:72.7.0*255(236.3*V)
#1-0:31.7.0*255(000.85*A)
#1-0:51.7.0*255(000.36*A)
#1-0:71.7.0*255(001.59*A)
#1-0:81.7.1*255(120*deg)
#1-0:81.7.2*255(239*deg)
#1-0:81.7.4*255(345*deg)
#1-0:81.7.15*255(000*deg)
#1-0:81.7.26*255(338*deg)
#1-0:14.7.0*255(50.0*Hz)
#1-0:0.2.0*255(ver.01,7249A01D,20211201)
#1-0:C.90.2*255(7249A01D)
#1-0:F.F*255(000000)
#1-0:C.5.0*255(001C0104)
#1-0:36.7.0*255(000155*W)
#1-0:56.7.0*255(000061*W)
#1-0:76.7.0*255(000297*W)
#1-0:1.8.0*96(00008.7*kWh)
#1-0:1.8.0*97(00112.5*kWh)
#1-0:1.8.0*98(00475.6*kWh)
#1-0:1.8.0*99(00000.0*kWh)
#1-0:1.8.0*100(01263.7*kWh)
#!
#␃1
# NETDEV 0
# SPEED 5
# TRIGGERTIME 1703863512.52304
# DEVICES:
#
# 5
#
# RULECACHE:
#
Zähler ist von ZPA
Zitat von: huhu am 13 November 2023, 12:29:15Hallo zusammen,
erstmal herzlichen Dank für diese tolle Lösung!
Ich habe die Anleitung 1:1 aus dem ersten Post umgesetzt, nur leider bekommt er keine Verbindung und ich weiß nicht warum, hat jemand eine Idee?
Der Webserver ist auf true gesetzt, das Device in FHEM habe ich mehrfach neu angelegt.
Im Log bekomme ich die Meldung, dass er nicht errechbar ist. Die IP Adresse ist korrekt.
2023.11.13 12:23:10 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:13 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:16 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:19 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:22 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:25 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:28 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:31 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:34 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:37 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:40 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:43 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
2023.11.13 12:23:46 1: OBIS (Tibber) - Error connect to http://196.168.1.63:80 timed out
Wenn ich die URL im Browser mit Benutzer Passwort öffne, bekomme ich die gleiche Rückmeldung, die auch unter Nodes/Data auf der Bridge angezeigt werden.
Curl gibt mir die 1b1b1 Blöcke zurück, also auch gut. Nur FHEM möchte irgendwie nicht :'(
Viele Grüße
Frohes neues Jahr zusammen!
Ab heute bin ich nun auch Tibber Kunde und wollte mich nochmal mit der Ausleseproblematik beschäftigen. Leider bekomme ich in FHEM nach wie vor keine Verbindung zum Pulse hin.
Webserver ist dauerhaft an, CURL geht, die Json-URL über einen Browser liefert auch Werte.
Testweise habe ich eine andere FHEM Instanz auf einem anderen PI probiert, gleiches Ergebnis: Error connect time out.
Der Status ist meist ???, manchmal aber auch disconnected
Die 47_OBIS.pm ist von
47_OBIS.pm 28127 2023-11-05 14:40:42Z gvzdus
Jemand einen Tipp, woran es liegen könnte?
Bringt die Verlängerung des Intervall-Wertes vielleicht etwas (bei mir: 30)?
Ich habe eine Information im Netz gefunden, wie man noch weitere Werte über die Bridge und den Pulse bekommen kann:
http://admin:[password]@192.168.xx.xx/metrics.json?node_id=1
U.a. ist hier der Batterie-Status des Pulse interessant.
Gruß
Blueberry63
Hallo,
ich verwende das OBIS Modul seit einem knappen Jahr. Jetzt möchte ich die Wattzahl der einzelnen Phasen berechnen. Ich bin davon erstmal davon ausgegangen, dass die richtige Formel um auf den power-Wert zu kommen die Folgende ist :
current_L1 * voltage_L1 + current_L2 * voltage_L2 + current_L3 * voltage_L3
Leider kommt dabei nicht das Richtige raus. Kann mir bitte jemand einen Tipp geben? Hier meine Readings:
readings_tibberpulse.png
Vielen Dank im Voraus und schöne Grüße,
Buhau75
Wie sieht denn Dein UserReading für die einzelne Phase aus (power_L1)?
Vor allem: Da steht doch schon "power" im Output.
"power" sowie "total_consumption" kommen eigentlich bei jeder mME, die ich kenne (sofern die PIN eingegeben wurde)