@paresy
mich würde aber interessieren warum Windows und linux sich da sich unterschiedlich verhalten. Kannst Du dir das erklären? Letzten Endes habe ich das RegisterMessage von Zeile 22 runter auf unter Zeile 38 geschoben.
trat bei mir auch auf einem RasPi4 mit Symcon 7.0 auf, und das ist ja eher ein Linux Derivat.
Hier läuft das ganze jetzt.
Sorgen bereitet mir nach wie vor das System (Symcon 6.3) welches im Docker Image auf einer QNAP TS464eU läuft, würde mich wundern wenn QTS auf Windows aufbaut.
Sobald ich versuche das Modul über den Modul Store zu installieren:
Wär schön wenn auch das zweite System wieder laufen würde; dann können wir anschliessend schauen wo denn der Grund für die noch vermutlich folgenden Aussetzer zu suchen ist; tippe mal auf Tibber weil bei mir beide immer zum selben Zeitpunkt ausstiegen.
Dann dauert ggf die Verarbeitung geringfügig länger und hängt? Irgendeine Erklärung muss es ja geben, wenn es ausreicht, einfach das RegisterMessage Zeilenmäßig zu verschieben.
Wie kommst du drauf das die Guid falsch ist? Es ist die vom Tibber-Modulpaket. Die Findest du in der Library.json und hat sich auch nicht geändert.
Hast Du im Module-Control (also Kern-Instanzen → Modules) noch irgendwas von Tibber drin? Von Philipp oder von mir? Oder Testing?
Ist es eigentlich gewollt, dass im Dropdown-Menü „Heim auswählen“ immer ein leerer String an erster Position steht, der nicht funktioniert (betrifft beide Module)?
Ich hätte eigentlich erwartet, in dem Dropdown-Menü nur valide Heime zu finden oder alternativ einen Platzhalter, wie „kein Heim ausgewählt“.
Hat man seinem Zuhause bei Tibber keinen Spitznamen gegeben, dann ist das ebenfalls ein leerer String, sodass man dann ein Dropdown-Menü mit zwei leeren Felder hat, von denen nur das zweite funktioniert. Das ist ein wenig verwirrend, finde ich.
gestern um 6,37 Uhr war es bei mir wieder soweit, beide waren gleichzeitig ausgestiegen.
Erstaunlicherweise ist der erste von beiden dann irgend wann wieder losgelaufen; kann aber leider nicht sagen wann, da ich dort nach massiven Updateproblemen auf die V7 unter Docker es versäumt hatte diese Variablen zu loggen.
Bin ich der einzige bei dem Tibber_Realtime ausgestiegen ist?
falls nicht wäre es interessant zu erfahren wann.
mfg
Bernd
PS: hab nen Script angelegt mit welchem ich den Port schliesse und wieder öffne, danach lüppt dat wieder.
Man könnte das durch nen Timer ergänzen welcher bei jedem Dateneingang zurück gesetzt wird; hilfreich noch eine Benachrichtigung auf´s Handy.
Hallo berndj1,
bei mir gibt es das identische Problem.
Bei mir gibt es noch ein schlimmeres Problem, nach Neustart von Symcon ist der Tibber Realtime Webclient kaputt und das Modul lässt sich nicht mehr starten, weil es die Schnittstelle nicht findet.
Zur Zeit zeige ich nur die Zählerstände an und schreibe Datum und Uhrzeit der letzten Aktualisierung in die Anzeige Kategorie, damit ich sehe, ob Tibber wieder „hängt“. Daher bin ich zur Zeit da noch entspannt.
Hatte bis jetzt wenig Zeit und Muße das detailliert zu melden.
Bin zwar nicht @paresy , was aber auf jeden Fall keine gute Idee ist; im Create schon mehr zu machen als die Instanz zu erstellen.
Gerade wenn Symcon startet, wird create ausgeführt, noch bevor alle Instanzen und somit Funktionen bereit stehen.
IPS_GetInstance wird gerne versagen und dir nur eine Fehlermeldung bringen.
GetRtApi fängt schon an extern mit dem Dienst zu reden, dabei sollte das immer erst wenn der Kernel Ready ist und Applychanges schon gelaufen ist passieren.
Ebenso sollte ConfigParentIO nicht im Create erfolgen, weil auch hier IPS_GetInstance, IPS_SetConfiguration und IPS_ApplyChanges eventuell nicht funktionieren.
nö, wieso? Du könntest Dir ja das Preis Array anschauen und vergleichen (der Wert hinter Price:) das das Array 5 Sekunden später geschrieben wird liegt daran, das erst mit den Werten gearbeitet wird und am ende die Werte ins Array geschrieben werden.
Ich kann das bei mir auch nachstellen.
Da scheint beim Timing der Timer ein kleines Problem zu sein.
Das Array wird um 00:00:15 aktualisiert (Zeile 424) der Aktuelle Preis wird aber immer xx:00:10 aus dem Array aktualisiert. Somit wird um 00:00:10 noch aus dem „alten“ Array gelesen und somit der Wert für die Stunde „0“ vom Vortag genommen.
@Kris: ich denke das Update des Arrays auf 00:00:05 zu setzen sollte das Problem lösen, und die 5 Sekunden sollten der API trotzdem genug Zeit geben, den Tagesverschieber zu erledigen.