Vielen Dank an Matthias, dass er so aktiv in die Entwicklung des Adapters eingestiegen ist.
Nutzt man Forecast.solar als Dienst, kann man das Aktualisierungsintervall einstellen, bei Solcast nicht. Da wird doch nur einmal in der Nacht aktualisiert wenn ich mich recht erinnere. Warum wurde das so implementiert? Man hat bei Solcast 50 Api-Aufrufe / 24h frei, ich sehe zumindest darin kein Problem, nicht alle paar Stunden die Prognose für den Tag zu aktualisieren.
Bisher nur einmal in der Nacht zu aktualisieren, hat erhebliche qualitative Nachteile für die Prognosegüte des restlichen Tags. Vergleicht man die nächtliche Prognose aus dem Adapter mit der sich auf der Homepage von Solcast regelmäßig aktualisierenden Prognose, so wird die vor allem nach Sonnenaufgang erheblich exakter. Ist auch logisch, denn Solcast arbeitet neben Modellvorhersagen auch stark mit der Analyse von Satbildern, deren Qualität nach Sonnenaufgang erheblich zunimmt. Ich weiß nicht ob es einen technischen Grund gibt, keine regelmäßige Aktualisierung bei Solcast zu implementieren. Vielleicht weil von der API die Prognosedaten nur ab dem Zeitpunkt der Aktualisierung ausgegeben werden und nicht rückwirkend bis zum Tagesbeginn? Hier würde ich stark dafür plädieren, einen Workaround zu implementieren, indem man die 30minütigen alten Prognosedaten bis zum Zeitpunkt der Aktualisierung und dann ab da mit den erneuerten Daten kombiniert und ggf. manuell eine Summe für die 24h-Prognose bildet.

Grüße,
Bastian

@alinaclg said in Test PV Forecast Adapter:

@oxident ich bin dabei - leider gibt kachelmannwetter.com keine API raus. Oder nur sehr teuer. Ich habe die Erfahrung gemacht, dass die dort genannten Somnnenstunden mal 0.5 bei mir passt. Bei euch wären es sicher andere Faktoren über 1. Wer mag, einfach mal schauen

Wetter

Alina

Es gibt eine offizielle API: https://api.kachelmannwetter.com/v02/_doc.html#/ aber in der Tat nicht für lau. 6,99€/Monat, die Datenqualität und Auswahl ist dafür überragend. Aber nur für einen Vorhersage-Adapter in der tat zu teuer.

@intruder7 Ich hatte nochmal ein paar Stunden investiert - der selbe Ausgang. Im LXC-Container funktioniert bei mir nach wie vor nur der Conbee II.

Hallo und danke für die großartige Arbeit an Jarvis, ich bin mir sicher, dass ich meine Steuerung zukünftig komplett darauf migrieren werde.

Bisher habe ich meine io-Broker-Visualisierung mit HabPanel realisiert. Damit kann ich auf dem Handybildschirm z.B. vier Schaltwidgets in einer Zeile anordnen:

Jarvis skaliert auf meinem Handy so, dass nur zwei Schalter nebeneinander passen.

Ich habe das Feature-Voting gesehen und das zukünftig eine Möglichkeit zur Konfiguration der Skalierung hinzukommen soll. Ich wollte mit den Screenshots nochmal verdeutlichen, dass ich finde, für eine Handy-Visualisierung ist aktuell noch Optimierungspotential.

Noch eine Funktion aus Habpanel, die ich sehr schätze - vielleicht auch mal was für die Zukunft: Man kann das Menü zum Umschalten zwischen Tabs links statt oben anordnen und dann per Swipe-Geste ein- und ausblenden:

@diginix said in Test PV Forecast Adapter:

@bastian-m Wie machst du denn jetzt den ganzen Vergleich in deinem Skript mit einer (unbekannten) Menge an Objekten?

Mit einem Blocky des Todes Ich durchlaufe in einer Schleife alle 15-Min-Intervalle von 7 bis 18 Uhr und simuliere für jede dieser möglichen Einschaltzeiten, wie viel Eigenverbrauch der Verbraucher abgreifen würde und gebe dann die Startzeit mit dem höchsten Eigenverbrauch aus.
Ich muss mal ein bisschen JavaScript lernen...grundlegendes prozedurales Programmieren beherrsche ich schon...aber...naja...in den 90er im Informatik-LK hat man halt Pascal gelernt. Falls einer die Sprache noch kennt.

Ich nutze forecast.solar mit Abo und nicht solcast - ich habe die Prognosen noch nicht systematisch mit dem tatsächlichen Ertrag verglichen, aber so schlecht passen die nicht. Um zumindest grob zu entscheiden ober der Verbraucher die Nacht duchläuft oder am nächsten Tag, reicht das.

Je mehr ich mich in die Dokumentation auf der Solcast-Webseite einlese, desto mehr bin ich überzeugt, dass die einmalige Aktualisierung der Prognose pro 24h die Qualität deutlich mindert. Solcast arbeitet neben der Nutzung von numerischen Wettervorhersagemodellen auch mit einer hochfrequenten Auswertung hochaufgelöster Satellitenbilder um Wolkenbedeckungen vor allem für die nächsten Stunden zu prognostizieren. Dadurch, dass sich die Solcast-Prognose nur einmal in der Nacht aktualisiert (gerade hier sind die Sat-Bilder übrigens besonders schlecht, weil nur Infrarot-Aufnahmen zur Verfügung stehen) wird, ist die Prognose vor allem für die zweite Tageshälfte häufig deutlich schlechter als die am frühen Vormittag manuell auf der Solcast-Webseite aufgerufene. Es stehen doch auch in der kostenfreien Version der Solcast-Webseite genügend API-Aufrufe zur Verfügung, um die Prognose alle 4 bis 6 Stunden zu aktualisieren. Sprach da irgendetwas konkret gegen?

Und zum Thema Solcast v.s. Forecast.Solar:
Ich lasse beide Dienste in einer jeweils eigenen Adapterinstanz laufen und Vergleiche die Prognosen mit der tatsächlichen Produktion meiner PV-Anlage. Bisher ist Solcast trotz der nur einmaligen Aktualisierung der Prognose in der Nacht besser als Forecast.Solar (obwohl ich Forecast.Solar in 15min-Auflösung via Abo zur Verfügung habe)

@da_woody said in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:

@bastian-m die devs lesen da sicherlich mit, ein request auf GitHub ist doch der bessere Weg...

Da hast du völlig Recht. Request bei GitHub ist eröffnet.

Gruß,
Bastian

Ist beim Entwicklerteam eigentlich soweit alles in Ordnung? Mir ist gerade aufgefallen, dass es zumindest im Github-Repo seit November keinen Commit mehr gab.

Natürlich will Gut Ding Weile haben und jeder macht mal Pause und hat wichtigeres zu tun, noch dazu bei einem Freizeitprojekt. Ich hoffe, @Zefau geht's gut.

Gruß,
Bastian

Ist beim Entwicklerteam eigentlich soweit alles in Ordnung? Mir ist gerade aufgefallen, dass es zumindest im Github-Repo seit November keinen Commit mehr gab.

Natürlich will Gut Ding Weile haben und jeder macht mal Pause und hat wichtigeres zu tun, noch dazu bei einem Freizeitprojekt. Ich hoffe, @Zefau geht's gut.

Gruß,
Bastian

@io_laurent Ich habe mir das zum Anlass genommen, auf meinem Proxmox-Server einen LXC-Container mit pihole anzulegen. Für das "Problem" des nahtlosen Übergangs zwischen HeimWlan und Mobilfunknetz gibt es unter Android den alternativen WireguardClienten "WG Tunnel", in dem man eine WhiteList mit WLAN-SSIDs definieren kann, in denen die Verbindung direkt und ansonsten per VPN hergestellt wird. Funktioniert bei mir seit einer Woche völlig solide. Und noch wichtiger: Bei meiner Frau auch!

@io_laurent Bedeutet, dein Handy ist dauerhaft über deinen Heimischen Zugang via VPN im Netz, oder hast du es irgendwie so gestaltet, dass wenn du Jarvis startest, er ggf. die VPN-Verbindung startet?

Ich teste gerade Jarvis 3.2RC und bin versucht, meine über Jahre gewachsene Visualisierung vom alten iobroker-Habpanel-Adapter auf Jarvis zu portieren. Ich habe hier bereits recherchiert, wie ein Zugriff auf Jarvis von außerhalb des WLANs möglich ist. Gefunden habe ich hier bisher die Möglichkeiten per VPN z.B. via Wireguard über meine Fritzbox oder via Reverse-Proxy.
Für meine alte Visualisierung habe ich bisher die iobroker-App und einen iobroker.pro-Zugang benutzt. Der unschlagbare Vorteil dieses Systems ist, dass der WAF (woman acceptance factor) quasi 100% beträgt. Meine Frau steuert unser Haus von ihrem Handy aus klaglos mit der iobroker-App, da die App selbst detektiert, ob das Gerät im lokalen WLAN ist oder nicht und entsprechend automatisch die Habpanel-Visu lokal oder über iobroker.pro holt und die Login-Daten auch noch zuverlässig gespeichert sind. Für dieses Weibchen-kompatible System habe ich bisher keine Idee, wie ich das mit Jarvis umsetzten kann, da die aktuellen Jarvis-Versionen ja fix Port 8400 benutzen und damit der Zugriff über iobroker.pro von extern nicht funktioniert.
Hat jemand eine Lösung dafür?

Oder alternativ: Die Projekte werden ja von unterschiedlichen Personen betrieben - ob da eine Abstimmung möglich wäre, dass iobroker.pro zukünftig auch Jarvis 3.2 unterstützt?

Ich bin mir nicht sicher, welche beteiligten Instanzen bzw. Personen für mein Anliegen alle tätig werden müssten:

Ich portiere gerade meine über Jahre gewachsene Visualisierung vom alten iobroker-Habpanel- zum Jarvis-Adapter. Dieser funktioniert mit der iobroker-App nur lokal im WLAN, von extern über iobroker.pro geht es nicht, da Jarvis fix mit dem Port 8400 arbeitet. Mir fehlt das technische Wissen um zu verstehen, warum das so gemacht wird und ob es umsetzbar wäre, dass auch Jarvis 3.2 wieder mit der iobroker-App und über iobroker.pro funktionieren kann.
Für mich geht mit Jarvis gerade der unschlagbare WAF-Faktor verloren, dass meine Frau unser Haus mit ihrem Handy beliebig bedienen kann, egal ob über WLAN oder von extern.

Könnte es da einen Lösungsansatz geben?

@hunduster sagte in jarvis v3.0.0 - just another remarkable vis:

Kurze Zwischenfrage am Rande von einem Jarvis-Einsteiger: Mit welchen Widget-Elementen machst du diese schöne simple Darstellung mit jeweils dem großen Icon, Unterschrift + Datenwert

Liebe Grüße und schönes Wochenende!
Bastian

Das Problem bleibt auch weiterhin ein Mysterium. Ich kann auf dem Conbee-3 mittlerweile in einem LXC-Container sogar via GCFFlasher die Firmware updaten und habe gerade testhalber mal Zigbee2Mqtt im selben LXC-Container installiert. Der Conbee3 wird problemlos angesprochen und ich konnte eine Lampe pairen. Ich bin gespannt, was Dresden Elektronik aus meinen Debug-Logs macht, denn so einfach wie es von denen zuerst hingestellt wurde, dass es bestimmt ein Rechteproblem in meinem Container ist, kann es dann ja nicht sein. Ich wette, da ist noch irgendwo ein Bug in deconz. Ich habe zwar schon länger mit Zigbee2mqtt geliebügelt, aber so richtig Interesse habe ich nicht daran, meine 80 devices neu zu pairen und die Scripte anzupassen...
Es lohnt sich wahrscheinlich, den Thread im Deconz-Forum dazu weiter zu verfolgen.

Wer sich für die Thematik interessiert, kann meinen Thread dazu im Support-Forum von Dresden Elektronik verfolgen:
https://forum.phoscon.de/t/conbeeiii-setup-in-proxmox-lxc-container/4885

Die Kombination aus dem Conbee III und einem LXC-Container scheint bisher ein ungelöstes Problem zu sein. Ich stehe seit Anfang des Jahres vor dem selben Problem. Die Anleitungen, mit denen ich zuvor meinen Conbee II erfolgreich durchgereicht habe, funktionieren adaptiert für den Conbee III nicht. Es gibt in diversen Foren immer wieder die selben Berichte von unterschiedlichen Usern dazu und soweit ich das überblicke, konnte das Problem niemand lösen. In einer Proxmox-VM funktioniert es. Ich würde fast wetten, es ist ein Firmware-bezogenes Problem des Sticks... Ich versuche aktuell Kontakt diesbezüglich zu Dresden Elektronik aufzunehmen.

@intruder7 Genau, irgendwann wird es eine Lösung für den Conbee III im LXC-Container geben. Entweder warten und bis dahin den Conbee II benutzen oder wenn ich unbedingt den Conbee III schon benutzten möchte als temporären Workaround noch okay fände: deconz vorübergehend auf dem LXC-Host installieren. Das ist in zwei Minuten aufgesetzt und ebenso schnell die Konfiguration gebackupt... Könnte ich übergangsweise auch mit leben.