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.
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).
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?
hab mal einen kleinen Fix hochgeladen, @berndj1 probiere mal ob das dein Problem löst, wenn nicht, habe ich noch eine andere idee, aber probieren wir erstmal die hier.
Hab das Modul auch auf Anhieb erfolgreich einsetzen können. Auch wenn ich erst zum 01.01.24 starten kann, bekomme ich trotzdem schon die vollen Daten, weil ich ja schon als Kunde registriert bin.
Ich habe mir noch ein paar Daten aus dem „Preis Array“ per Skript extrahiert, damit ich diese als Variablen habe und ggf. weiterverwenden kann.
Falls es jemand braucht oder man integriert es in das Modul:
<?php
//"Preis Array" aus dem Modul Tibber wird eingelesen
$Array=json_decode(getvalue(43671), true);
// Initialisiere der Variablen
$minPrice = PHP_INT_MAX;
$minPriceIdent = '';
$maxPrice = PHP_INT_MIN;
$maxPriceIdent = '';
$levelCount = array('VERY_CHEAP'=>0,'CHEAP'=>0,'NORMAL'=>0,'EXPENSIVE'=>0,'VERY_EXPENSIVE'=>0);
//durchlaufe das Array, um den geringste und höchsten Preis inkl. Stunde (Ident) für morgen zu finden
for ($i = 24; $i <= 47; $i++)
{
$currentPrice = $Array[$i]['Price'];
//geringster Preis
if ($currentPrice < $minPrice)
{
$minPrice = $currentPrice;
$minPriceIdent = $Array[$i]['Ident'];
}
//höchster Preis
if ($currentPrice > $maxPrice)
{
$maxPrice = $currentPrice;
$maxPriceIdent = $Array[$i]['Ident'];
}
}
//durchlaufe das Array, um die Anzahl der verschiedenen Preislevel für morgen zu ermitteln
for ($i = 24; $i <= 47; $i++)
{
$level = $Array[$i]['Level'];
$levelCount[$level]++;
}
//gib den geringsten und höchsten Preis aus
SetValueFloat(43781, $minPrice);
$minTime=intval(substr($minPriceIdent, 9)); //Uhrzeit (Stunde), in welcher der niedrigste Preis gilt
SetValueInteger(20177, $minTime);
SetValueFloat(56419, $maxPrice);
$maxTime=intval(substr($maxPriceIdent, 9)); //Uhrzeit (Stunde), in welcher der hächste Preis gilt
SetValueInteger(58619, $maxTime);
$Spanne=$maxPrice-$minPrice; //Preisspanne zwischen min und max
SetValueFloat(26593, $Spanne);
//Zuordnung der Preislevel zu Variablen
//Anzahl der Preislevel am Folgetag
SetValueInteger(50577, $levelCount['VERY_CHEAP']);
SetValueInteger(37736, $levelCount['CHEAP']);
SetValueInteger(55914, $levelCount['NORMAL']);
SetValueInteger(49177, $levelCount['EXPENSIVE']);
SetValueInteger(19442, $levelCount['VERY_EXPENSIVE']);
war gestern vor Ort und hab als erstes mal dieses Problem:
durch Einsatz dieses:
gelöst.
Ich bin zwar Informatik-Betriebswirt, aber das Modul war dann doch eine Herausforderung um es zum Leben zu erwecken.
Fazit: dort bekomme ich jetzt alle 3 Leistungswerte der jeweiligen Phasen!
Tibber selbst antwortete auf den Wunsch diese 3 Werte in die API mit aufzunehmen sehr schwammig, evtl. hilft es ja wenn ich nicht der einzige wäre, deshalb hier als Hilfestellung meine Antwort an tibber:
Hallo xxx,
Ihr macht Werbung mit dem Hinweis: Wir helfen euch Energie einzusparen und
diese 3 sehr wichtigen Werte,
welcher dieser Zähler glücklicherweise liefert, werden dem Kunden vorenthalten?
Die API unterstützt die einzelnen Ströme der 3 Phasen (bei wenigen Zählern), liefert aber leider nicht die zwingend notwendigen Daten zur Phasenverschiebung, welche man benötigen würde um die Leistung selber zu berechnen.
Ärgerlich ist es bei Kunden welche einen Zähler mit 3 getrennten Rücklaufsperren besitzen und eine der sogenannten PV-Balkonanlagen nutzen;
aber keine Ahnung haben auf welcher Phase ihre Balkonanlage sitzt.
Da kann es dann schon mal passieren dass man 600 Watt auf L1 einspeist, 250 an L2 und 400 Watt an L3 verbraucht und einem dann 650 Watt berechnet werden.
Ich würde mir von euch eine Liste wünschen, ähnlich der „White“ Liste der kompatiblen Zähler zum Pulse auf welcher detailliert die von tibber zur Verfügung gestellten Werte der API gelistet wären.
Anderes Thema: Probleme mit Logarex Zählern, kurzer Tip an eure Entwicklungsabteilung:
die Firma ELV in Leer empfiehlt die Modifikation Ihrer IR Leseköpfe aus folgendem Grund:
das IR Signal ist derart niedrig; da muss der Verstärkungsfaktor im Empfangsteil erhöht werden.
Googeln hilft.
mfg
Nun zum Problem mit dem Abbrechen bei dem Livedatenmodul.
Fehlermeldung:
Konnte Konfigurationsform nicht laden
Instanz hat diese Funktion nicht implementiert (Code: -32603)
Mir ist aufgefallen, wenn die Verbindung ausfiel, bekam ich auf der Instanz (nicht in der IO Instanz) keinen Zugriff mehr auf den Token und die weitere Auswahl, evtl. hilft es ja.
Zum aktuellem Stand bei mir:
die Spielereien auf einem System beide Tibberaccounte abzufragen habe ich verworfen; die laufen beide getrennt vor sich hin.
Erstaunlicherweise sind beide trotzdem gestern zur selben Zeit ausgefallen, werde sie jetzt erneut aufsetzen und dann melde ich mich dazu.
neues Problem beim erstellen einer zweiten Instanz, Fehlermeldung:
Konnte Instanz nicht erstellen
Warning: Das Registrieren von einer ‚Property‘ ist nur in der Create-Methode möglich. in /var/lib/symcon/modules/.store/de.treasy79.tibber/Tibber_Realtime/module.php on line 38
(Code: -32603)
Aber seit wann rechnet ein Versorger einzelne Phasen ab? Die Rücklaufsperre soll nur dafür sorgen das der Zähler nicht rückwärts läuft. In Deinem Beispiel würde nur 50 Watt berechnet da über die Gesamtleistung abgerechnet wird.
[quote=„berndj1, post:27, topic:135112“]
Mir ist aufgefallen, wenn die Verbindung ausfiel, bekam ich auf der Instanz (nicht in der IO Instanz) keinen Zugriff mehr auf den Token und die weitere Auswahl, evtl. hilft es ja.[/quote]
Ich habe den Websocket mal ein paar tage auf meinem Testsystem laufen lassen, nebenher auch einige MB DEBUG erzeugt. Das Teil lief stabil durch.
Gestern habe ich wieder auf mein livesystem geschaltet (natürlich ohne debug) da ist er mir auch irgendwann ausgestiegen
die vorherige Fehlermeldung bezog sich auf das entfernte System, Zugriff per VPN, Fritzbox, Symcon auf´m RasPi4.
Nun zum Versuch soeben mein hiesiges System (UBNT Netzwerk, Symcon läuft im Docker auf einer QNAP), Fehlermeldung:
Es gibt einen Konflikt mit einer Bibliothek, die im Module Control installiert ist. Bitte deinstallieren Sie Tibber bevor Sie die Installation wiederholen.
Hab gelöscht und dann versucht neu anzulegen (allerdings ohne die alten Instanzen zu löschen),
Fehlermeldung:
Konnte Bibliotheksdaten nicht abfragen
Bibliothek mit der GUID {009BAE4A-6A6A-8E0A-09CF-C0178B27B2CE} nicht gefunden (Code: -32603)
Schön schiet!
mfg
Bernd
Zum Thema Rücklaufsperre: mittlerweile ist der alte Standard mit dem Begriff „saldierend“ nicht mehr selbstverständlich.
Wenn ich an meine ersten Versuche mit dem SML Protokoll denke fällt mir wieder ein wie frustriert ich war als ich erfuhr dass die Netzbetreiber nur noch Zähler mit sehr, sehr wenigen Daten bestellen und beispielsweise EMH mitteilte dass der von mir käuflich erworbene Zähler zwar mein Eigentum sei, ich aber keinerlei Anspruch auf weitergehende Daten; auch nicht gegen entsprechendes Endgelt habe.
@mknee@berndj1
Könnt Ihr mal das Meldungsfenster öffnen, eine Realtime-Instanz anlegen und schauen welche Meldung im Meldungsfenster erscheint? Das wäre interessant. Ich bekomme den Fehler in der 7 nicht nachgestellt.
auf dem entferntem System war die erste Vermutung, lösch doch die noch vorhandene Instanz, versuch es noch mal, evtl. ist das Verhalten dann anders, dachte ich…:
Zum Lokalisieren des Problems beim Erstellen hab ich dann noch auf meinem uralten System (läuft seit 2009 mit über 20 GB Speicher für die geloggten Daten, Win7, Symcon 6.1) eine jungfräuliche Instanz über den Modulmanager erstellt, zunächst ohne Modul.
Dann beim Erstellen einer Tibber_realtime_Instanz folgendes:
Konnte Instanz nicht erstellen
Warning: Das Registrieren von einer ‚Property‘ ist nur in der Create-Methode möglich. in C:\ProgramData\Symcon\modules.store\de.treasy79.tibber\Tibber_Realtime\module.php on line 38
(Code: -32603)
mfg
Bernd
PS: gerade noch bemerkt, mein zweites System auf dem Docker nutzt Symcon V6.3
Sobald ich eine Tibber_Realtime Instanz unter Symcon 7 unter Windows 11 einrichten möchte kommt der Fehler
Konnte Instanz nicht erstellen
Warning: Das Registrieren von einer 'Property' ist nur in der Create-Methode möglich. in C:\ProgramData\Symcon\modules\.store\de.treasy79.tibber\Tibber_Realtime\module.php on line 38
(Code: -32603)
