[Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM
-
eben, aber wenn ich den Chart fertig vordefinieren soll müsste der entsprechende DP in der Konfig mit abgefragt werden. Oder wie siehst du das?
@Thisoft sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Oder wie siehst du das?
Extra einen Datenpunkt anzulegen der einen weiteren Datenpunkt erzeugt der das selbe macht halte ich nicht für zielführend. Ein bisschen Konfigurationsarbeit kann man auch dem User überlassen, da müsstest du nur mit "const" arbeiten ganz am Anfang des scriptes wo er seinen Datenpunkt selbst einfügen kann. Ich denke mal für die Veröffentlichung wirst du sicher auch github verwenden, da schreibst du eine schöne readme.
Wobei, ich weiss jetzt nicht wie du das Script letztendlich baust, aber mit einem Datenpunkt der einfach gerade die ist-Leistung ausgibt ist es doch nicht getan, es müsste doch auch in eine json oder in influxdb gespeichert werden.
Mit echarts bekommt man ganz schöne Diagramme hin und es ist einfach einzustellen. Evtl. ist es gar nicht nötig extra Scripte zu schreiben.
Grüße H5N1
-
@Thisoft sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Oder wie siehst du das?
Extra einen Datenpunkt anzulegen der einen weiteren Datenpunkt erzeugt der das selbe macht halte ich nicht für zielführend. Ein bisschen Konfigurationsarbeit kann man auch dem User überlassen, da müsstest du nur mit "const" arbeiten ganz am Anfang des scriptes wo er seinen Datenpunkt selbst einfügen kann. Ich denke mal für die Veröffentlichung wirst du sicher auch github verwenden, da schreibst du eine schöne readme.
Wobei, ich weiss jetzt nicht wie du das Script letztendlich baust, aber mit einem Datenpunkt der einfach gerade die ist-Leistung ausgibt ist es doch nicht getan, es müsste doch auch in eine json oder in influxdb gespeichert werden.
Mit echarts bekommt man ganz schöne Diagramme hin und es ist einfach einzustellen. Evtl. ist es gar nicht nötig extra Scripte zu schreiben.
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Extra einen Datenpunkt anzulegen der einen weiteren Datenpunkt erzeugt d
Nein, so meine ich das nicht. Ich meine, dass der User einfach in der Konfiguration seinen DP mit den Istwerten angibt. Diesen kann man dann ja auslesen. Natürlich muss dieser "historisiert" sein...
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
da müsstest du nur mit "const" arbeiten ganz am Anfang des scriptes wo er seinen Datenpunkt selbst einfügen kann. Ich denke mal für die Veröffentlichung wirst du sicher auch github verwenden, da schreibst du eine schöne readme.
Ich denke eigentlich so ein wenig darüber nach das Script bzw. den Code direkt in den Adapter zu integrieren. Dieser schreibt dann einen State mit dem HTML-Code...?!?
22 HM-Geräte; PivCCU2 auf RasPi
ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients
-
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Extra einen Datenpunkt anzulegen der einen weiteren Datenpunkt erzeugt d
Nein, so meine ich das nicht. Ich meine, dass der User einfach in der Konfiguration seinen DP mit den Istwerten angibt. Diesen kann man dann ja auslesen. Natürlich muss dieser "historisiert" sein...
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
da müsstest du nur mit "const" arbeiten ganz am Anfang des scriptes wo er seinen Datenpunkt selbst einfügen kann. Ich denke mal für die Veröffentlichung wirst du sicher auch github verwenden, da schreibst du eine schöne readme.
Ich denke eigentlich so ein wenig darüber nach das Script bzw. den Code direkt in den Adapter zu integrieren. Dieser schreibt dann einen State mit dem HTML-Code...?!?
@Thisoft sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Dieser schreibt dann einen State mit dem HTML-Code...?!?
Gute Idee, das wäre dann sozusagen ein Starter Packet ohne zusätzlich Adapter wie echarts installieren zu müssen. Dazu muss ich mir Gedanken machen über die Logik wie man es am besten in den Adapter bekommt und wie man das umsetzt mit den verschiedensten json Datenpunkte für einen Standort und wenn man mehrere (Ost, West, Gartenhaus und was weiß ich hat). Dazu muss ich wahrscheinlich die Konfigurationseite der Instanz unterteilen um es übersichtlicher zu halten. An der Struktur (ts: für timestamp und val: für wert) der json Datenpunkte will ich nichts ändern da sie für echarts so verlangt werden falls jemand doch echarts verwenden möchte, da muss ich universell denken.
Der Ansatz ist auf jeden Fall top.
-
Neue Version 1.1.3.
Es wurde das Sentry-Plugin hinzugefügt und ein entsprechender Eintrag in der README ergänzt.
-
Dieser Adapter nutzt die Sentry-Bibliotheken, um Ausnahmen und Codefehler automatisch an die Entwickler zu melden. Weitere Informationen und Anweisungen zum Deaktivieren der Fehlerberichterstattung finden Sie in der Sentry-Plugin-Dokumentation . Die Sentry-Berichterstattung wird ab js-controller 3.0 unterstützt.
-
Ich nutze meinen eigenen Sentry-Server, der auf Glitchtip basiert.
Changelog:
- (v 1.1.3) Sentry-Plugin hinzugefügt, um Fehler automatisch an Entwickler zu melden
- (v 1.1.2) Abhängigkeiten aktualisiert,
fix: [Link Text](Link Adresse)Aktualisierung des Rollentyps für Prognosedaten von „json“ auf „chart“.
Adapterupdate: Bitte den Adapter Stoppen, Update einspielen, kompletten Verzeichnisbaum löschen, Adapter starten und Verzeichnisbaum neu erstellen lassen.
Grüße H5N1
-
-
Neue Version 1.1.3.
Es wurde das Sentry-Plugin hinzugefügt und ein entsprechender Eintrag in der README ergänzt.
-
Dieser Adapter nutzt die Sentry-Bibliotheken, um Ausnahmen und Codefehler automatisch an die Entwickler zu melden. Weitere Informationen und Anweisungen zum Deaktivieren der Fehlerberichterstattung finden Sie in der Sentry-Plugin-Dokumentation . Die Sentry-Berichterstattung wird ab js-controller 3.0 unterstützt.
-
Ich nutze meinen eigenen Sentry-Server, der auf Glitchtip basiert.
Changelog:
- (v 1.1.3) Sentry-Plugin hinzugefügt, um Fehler automatisch an Entwickler zu melden
- (v 1.1.2) Abhängigkeiten aktualisiert,
fix: [Link Text](Link Adresse)Aktualisierung des Rollentyps für Prognosedaten von „json“ auf „chart“.
Adapterupdate: Bitte den Adapter Stoppen, Update einspielen, kompletten Verzeichnisbaum löschen, Adapter starten und Verzeichnisbaum neu erstellen lassen.
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Neue Version 1.1.3.
Es wurde das Sentry-Plugin hinzugefügt und ein entsprechender Eintrag in der README ergänzt.
-
Dieser Adapter nutzt die Sentry-Bibliotheken, um Ausnahmen und Codefehler automatisch an die Entwickler zu melden. Weitere Informationen und Anweisungen zum Deaktivieren der Fehlerberichterstattung finden Sie in der Sentry-Plugin-Dokumentation . Die Sentry-Berichterstattung wird ab js-controller 3.0 unterstützt.
-
Ich nutze meinen eigenen Sentry-Server, der auf Glitchtip basiert.
Changelog:
- (v 1.1.3) Sentry-Plugin hinzugefügt, um Fehler automatisch an Entwickler zu melden
- (v 1.1.2) Abhängigkeiten aktualisiert,
fix: [Link Text](Link Adresse)Aktualisierung des Rollentyps für Prognosedaten von „json“ auf „chart“.
Adapterupdate: Bitte den Adapter Stoppen, Update einspielen, kompletten Verzeichnisbaum löschen, Adapter starten und Verzeichnisbaum neu erstellen lassen.
Wenn es notwendig ist den ganzen Objektbaum neu anlegen zu lassen, dass ist das wohl eine inkompatible Änderung. Da sollte unbedingt ein MAJOR Update augeliefert werden. Bei einem Patch Update kann der User erwarten, dass nach dem Update alles unverändert weiterläuft.
Bitte beachten:
patch Update - nur Fehlerbehebungen, keine inkompatiblen Änderungen
minor Update - neue Funktionalitäte, keine inkompatiblen Änderungen
major Update - inkompatible ÄnderungenEntwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer 'nen Kaffee spendieren will: https://paypal.me
-
-
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Neue Version 1.1.3.
Es wurde das Sentry-Plugin hinzugefügt und ein entsprechender Eintrag in der README ergänzt.
-
Dieser Adapter nutzt die Sentry-Bibliotheken, um Ausnahmen und Codefehler automatisch an die Entwickler zu melden. Weitere Informationen und Anweisungen zum Deaktivieren der Fehlerberichterstattung finden Sie in der Sentry-Plugin-Dokumentation . Die Sentry-Berichterstattung wird ab js-controller 3.0 unterstützt.
-
Ich nutze meinen eigenen Sentry-Server, der auf Glitchtip basiert.
Changelog:
- (v 1.1.3) Sentry-Plugin hinzugefügt, um Fehler automatisch an Entwickler zu melden
- (v 1.1.2) Abhängigkeiten aktualisiert,
fix: [Link Text](Link Adresse)Aktualisierung des Rollentyps für Prognosedaten von „json“ auf „chart“.
Adapterupdate: Bitte den Adapter Stoppen, Update einspielen, kompletten Verzeichnisbaum löschen, Adapter starten und Verzeichnisbaum neu erstellen lassen.
Wenn es notwendig ist den ganzen Objektbaum neu anlegen zu lassen, dass ist das wohl eine inkompatible Änderung. Da sollte unbedingt ein MAJOR Update augeliefert werden. Bei einem Patch Update kann der User erwarten, dass nach dem Update alles unverändert weiterläuft.
Bitte beachten:
patch Update - nur Fehlerbehebungen, keine inkompatiblen Änderungen
minor Update - neue Funktionalitäte, keine inkompatiblen Änderungen
major Update - inkompatible Änderungen@mcm1957 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Da sollte unbedingt ein MAJOR Update augeliefert werden.
ich halte sowieso die Versionierung von @h5n1 sehr ambitioniert, solange wir im alpha-stadium sind.
Ruckzuck sind wir bei dem strikten Vorgehen bei einer zweistelligen Major Version, bevor der Adapter im Beta ist.Das kann es doch auch nicht sein!
-
-
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Neue Version 1.1.3.
Es wurde das Sentry-Plugin hinzugefügt und ein entsprechender Eintrag in der README ergänzt.
-
Dieser Adapter nutzt die Sentry-Bibliotheken, um Ausnahmen und Codefehler automatisch an die Entwickler zu melden. Weitere Informationen und Anweisungen zum Deaktivieren der Fehlerberichterstattung finden Sie in der Sentry-Plugin-Dokumentation . Die Sentry-Berichterstattung wird ab js-controller 3.0 unterstützt.
-
Ich nutze meinen eigenen Sentry-Server, der auf Glitchtip basiert.
Changelog:
- (v 1.1.3) Sentry-Plugin hinzugefügt, um Fehler automatisch an Entwickler zu melden
- (v 1.1.2) Abhängigkeiten aktualisiert,
fix: [Link Text](Link Adresse)Aktualisierung des Rollentyps für Prognosedaten von „json“ auf „chart“.
Adapterupdate: Bitte den Adapter Stoppen, Update einspielen, kompletten Verzeichnisbaum löschen, Adapter starten und Verzeichnisbaum neu erstellen lassen.
Wenn es notwendig ist den ganzen Objektbaum neu anlegen zu lassen, dass ist das wohl eine inkompatible Änderung. Da sollte unbedingt ein MAJOR Update augeliefert werden. Bei einem Patch Update kann der User erwarten, dass nach dem Update alles unverändert weiterläuft.
Bitte beachten:
patch Update - nur Fehlerbehebungen, keine inkompatiblen Änderungen
minor Update - neue Funktionalitäte, keine inkompatiblen Änderungen
major Update - inkompatible Änderungen@mcm1957 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Wenn es notwendig ist den ganzen Objektbaum neu anlegen zu lassen, dass ist das wohl eine inkompatible Änderung. Da sollte unbedingt ein MAJOR Update augeliefert werden. Bei einem Patch Update kann der User erwarten, dass nach dem Update alles unverändert weiterläuft
Das ist richtig, die letzten Updates greifen nicht in die Struktur ein, aber ich weiss zur Zeit nicht wer welche Version noch installiert hat, wenn ich mir die Statistik auf iobroker.dev anschauen sind noch welche mit den ersten Versionen unterwegs. Das soll nur eine Empfehlung sein um Fehler auszuschließen von alten Daten.
@Homoran sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
ich halte sowieso die Versionierung von @h5n1 sehr ambitioniert, solange wir im alpha-stadium sind.
Ruckzuck sind wir bei dem strikten Vorgehen bei einer zweistelligen Major Version, bevor der Adapter im Beta ist.Die ersten Versionen habe ich im GitHub im privat nicht im Public entwickelt, was soll ich machen, wenn ich zb etwas im Admin ändere das eine neue Funktion enthält, ist es kein Patch mehr, füge ich neue Icons oä ein ist es auch kein Patch mehr.
Grüße H5N1
-
-
@mcm1957 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Wenn es notwendig ist den ganzen Objektbaum neu anlegen zu lassen, dass ist das wohl eine inkompatible Änderung. Da sollte unbedingt ein MAJOR Update augeliefert werden. Bei einem Patch Update kann der User erwarten, dass nach dem Update alles unverändert weiterläuft
Das ist richtig, die letzten Updates greifen nicht in die Struktur ein, aber ich weiss zur Zeit nicht wer welche Version noch installiert hat, wenn ich mir die Statistik auf iobroker.dev anschauen sind noch welche mit den ersten Versionen unterwegs. Das soll nur eine Empfehlung sein um Fehler auszuschließen von alten Daten.
@Homoran sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
ich halte sowieso die Versionierung von @h5n1 sehr ambitioniert, solange wir im alpha-stadium sind.
Ruckzuck sind wir bei dem strikten Vorgehen bei einer zweistelligen Major Version, bevor der Adapter im Beta ist.Die ersten Versionen habe ich im GitHub im privat nicht im Public entwickelt, was soll ich machen, wenn ich zb etwas im Admin ändere das eine neue Funktion enthält, ist es kein Patch mehr, füge ich neue Icons oä ein ist es auch kein Patch mehr.
@H5N1 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
was soll ich machen,
das wollte ich von @mcm1957 wissen.
Ich halte die Versionierung, wie er schreibt für richtig und wichtig.
ABER nicht im alpha Stadium -
Version 1 ist per Definition eigentlich nicht mehr ALPHA. Dazu gibt es die 0er Versionen.
Die ersten Versionen habe ich im GitHub im privat nicht im Public entwickelt, was soll ich machen, wenn ich zb etwas im Admin ändere das eine neue Funktion enthält, ist es kein Patch mehr, füge ich neue Icons oä ein ist es auch kein Patch mehr.
Richtig. Das sind wären minor Versionen.
Aber ja, wenn das Kind schon mal in den Brunnen gefallen ist ist es schwer bis unmöglich es wieder raus zu kriegen. Da der Adapter derzeit noch nicht im Repo ist (das hab ich mit dem anderen openmeteo verwechselt) ist es nur halb kritisch. Bitte denk nur dran wenn der Adapter ins Repo kommt. User könnten sonst frustriert sein, wenn ein patch update ggF automatisch eingespeilt wird der in Wirklichkeit major ist.
Aber DANKE für deine intensive Arbeit.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer 'nen Kaffee spendieren will: https://paypal.me
-
Version 1 ist per Definition eigentlich nicht mehr ALPHA. Dazu gibt es die 0er Versionen.
Die ersten Versionen habe ich im GitHub im privat nicht im Public entwickelt, was soll ich machen, wenn ich zb etwas im Admin ändere das eine neue Funktion enthält, ist es kein Patch mehr, füge ich neue Icons oä ein ist es auch kein Patch mehr.
Richtig. Das sind wären minor Versionen.
Aber ja, wenn das Kind schon mal in den Brunnen gefallen ist ist es schwer bis unmöglich es wieder raus zu kriegen. Da der Adapter derzeit noch nicht im Repo ist (das hab ich mit dem anderen openmeteo verwechselt) ist es nur halb kritisch. Bitte denk nur dran wenn der Adapter ins Repo kommt. User könnten sonst frustriert sein, wenn ein patch update ggF automatisch eingespeilt wird der in Wirklichkeit major ist.
Aber DANKE für deine intensive Arbeit.
@mcm1957 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Version 1 ist per Definition eigentlich nicht mehr ALPHA. Dazu gibt es die 0er Versionen.
das meine ich ja mit
sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
ich halte sowieso die Versionierung von @h5n1 sehr ambitioniert, solange wir im alpha-stadium sind.
-
Version 1 ist per Definition eigentlich nicht mehr ALPHA. Dazu gibt es die 0er Versionen.
Die ersten Versionen habe ich im GitHub im privat nicht im Public entwickelt, was soll ich machen, wenn ich zb etwas im Admin ändere das eine neue Funktion enthält, ist es kein Patch mehr, füge ich neue Icons oä ein ist es auch kein Patch mehr.
Richtig. Das sind wären minor Versionen.
Aber ja, wenn das Kind schon mal in den Brunnen gefallen ist ist es schwer bis unmöglich es wieder raus zu kriegen. Da der Adapter derzeit noch nicht im Repo ist (das hab ich mit dem anderen openmeteo verwechselt) ist es nur halb kritisch. Bitte denk nur dran wenn der Adapter ins Repo kommt. User könnten sonst frustriert sein, wenn ein patch update ggF automatisch eingespeilt wird der in Wirklichkeit major ist.
Aber DANKE für deine intensive Arbeit.
@mcm1957 sagte in [Test Adapter] open-meteo-pv-forecast v1.1.x GitHub/NPM:
Bitte denk nur dran wenn der Adapter ins Repo kommt. User könnten sonst frustriert sein, wenn ein patch update ggF automatisch eingespeilt wird der in Wirklichkeit major ist.
Das ist mir bewusst, sollten es die Adapter in das stable Repo schaffen wird natürlich nicht verlangt das User alles löschen müssen ohne einen Hinweis. Hier im Forum habe ich es für richtig gehalten, um Fehler einer noch älteren Version auszuschließen.
Persönlich hätte ich jetzt noch eine Frage an @mcm1957, wenn wir schon bei den Versionierungen sind. Wenn ein Adapter im Latest ist und es ein Patch, Minor oder Major Update gibt, im iobroker.dev sehe ich (da jetzt eine Patch Version höher), bei den Adaptern die bereits im Latest sind, "Set as stable" gibt es dazwischen keine prüfung deinerseits mehr?
Support us
592
Online32.7k
Benutzer82.6k
Themen1.3m
Beiträge