Hauptmenü

Neueste Beiträge

#1
DOIF / Aw: Indirekter Zeittrigger mit...
Letzter Beitrag von xenos1984 - 30 März 2024, 00:18:32
Zitat von: Per am 29 März 2024, 20:26:29Das bleibt dir trotzdem lieber nicht erspart, ein Debugging ist, wg der vielen Rückmeldungen, nach der "alten" Methode vllt sogar einfacher.

Ja, natürlich, aber dann habe ich wenigstens sämtlichen Code in einem Device und nicht auf mehrere verteilt. Und ich kann dafür sorgen, dass zu jedem Zeitpunkt genau ein Zustand aktiv ist, und kann die Bedingungen in der von mir gewünschten Reihenfolge / Priorität abfragen. Einfacherer und übersichtlicherer Code ist eben auch einfacher zu debuggen.

(Natürlich könnte man den auch in eine myUtils Funktion packen. Aber ein DOIF Device hat dann auch noch Eingabefelder für Konfigurationsparameter und Readings, die ich anzeigen kann.)
#2
Anfängerfragen / Aw: weekdaytimer + isday
Letzter Beitrag von betateilchen - 29 März 2024, 23:49:29
Bisher habe ich noch nicht verstanden, was Du eigentlich tun willst.

Warum willst Du mit weekdaytimer arbeiten, wenn Du schon eine Lösung mit at hast, die funktioniert?

Formuliere doch mal die konkrete Aufgabe, anstatt hier wirre Dinge zu beschreiben, die Du probierst und die nicht funktionieren wie Du Dir das vorstellst.
#3
Server - Linux / Aw: Synology Container zusamme...
Letzter Beitrag von roemi - 29 März 2024, 23:41:12
Hallo Jürgen,

an welcher Stelle des Synology Docker Manager kann ich einem Container eine feste IP zuweisen?
Und die Container tauchen im DHCP-Server, in meiner Fall eine Fritz!Box, nicht auf. Also kann ich auch dort keine IP vergeben.
Zudem suche ich ja nach einer Möglichkeit zur Sicherstellung der Kommunikation innerhalb eines Docker Netzwerks.

Aber vielleicht liege ich auch falsch.

Römi
#4
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von Starkstrombastler - 29 März 2024, 23:20:48
@Hadl: Das hört sich insgesamt doch ganz gut an. Ich muss mich jetzt leider etwas kurz fassen, daher nur eine Anmerkung:

Zitat von: Hadl am 29 März 2024, 02:28:50Warum sollte denn nur der erste Wert nach einer Sekunde relevant sein. Das wäre dann z.B. der Anlaufstrom, wenn aber der Strom im Betrieb sinkt wäre das auch interessant.
Nein, es geht nicht um den Anlaufstrom (das spielt sich im Milli-Sekunden Bereich ab). Fragt man den Status des Shelly direkt nach dem Einschalten ab, bekommt man als Antwort 0 Watt, obwohl die Pumpe läuft. Weil das etwas blöd wäre, gibt es die 1 Sekunde Verzögerung. Das ist die Periode, mit der der Shelly Strom/Leistung ermittelt.

#5
Anfängerfragen / Aw: weekdaytimer + isday
Letzter Beitrag von lunepi - 29 März 2024, 22:44:30
Hm, jein vielleicht hab ich auch nur ein Denkfehler.

Es geht mir um den Morgen. Sorry hätte nicht meine ganze Zeile kopieren sollen:

06:30|on {sunrise_abs("REAL",0,"06:15","09:00")}|off

Wenn jetzt der Sonnenaufgang um 6:25 ist, wäre die Lampe den ganzen Tag an. Richtig oder?

Jetzt kann ich wenn ich es richtig verstehe die Zeile so schreiben:

06:30|on {sunrise_abs("REAL",0,"06:30","09:00")}|off

Richtig?

Das würde aber bedeuten, dass ich bei allen Änderungen immer 2 Zeiten nämlich "on" und den Sunrise ändern muss.
Das wiederum würde bedeuten das ich das meiner Frau beibringen muss, die das verändern von Zeiten liebt :}

Ich frage mich halt ob es sowas gibt wie ich das vorher mit at gemacht hab

*06:30 { if( !isday() ) { fhem("set FuSt.HC31B on-till " .sunrise_abs("REAL",0, "5:30","9:00")) }}

Hier ist es halt Wurscht, denn das wird ja nur ausgeführt wenn es noch nicht Tag ist.

Ich finde hat am weekdaytimer attraktiv, dass ich halt alle Zeiten Morgen Mittags abends und zwischendurch nutzen kann.

Ich stell mir das halt so ähnlich vor

{if (!isday()){06:30} }|on {sunrise_abs("REAL",0,"06:30","09:00")}|off

Oder bin ich auf dem Holzweg oder denke zu kompliziert?
#6
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 29 März 2024, 22:39:39
Der nächste Step könnte die Implementierung der Ensemble Modelle sein.
Allein der DWD stellt über sein Ensemble Regionalmodell ICON-D2 eine Vorhersage aus 20 Einzelmembern zur Verfügung.

Ein Auszug aus der Erläuterung auf der Webseite: https://www.dwd.de/DE/forschung/wettervorhersage/num_modellierung/04_ensemble_methoden/ensemble_vorhersage/ensemble_vorhersage_node.html

ZitatFür eine perfekte Wettervorhersage müssten jeder Prozess und jeder Zustand in der Atmosphäre genauestens bekannt und im Vorhersagesystem perfekt abgebildet sein. In der Realität ist das nur näherungsweise möglich. Bereits der erste Schritt zur Vorhersage – die Berechnung des gegenwärtigen Atmosphärenzustands – ist mit inhärenten Unsicherheiten behaftet. Diese und andere Unsicherheiten stellen eine Herausforderung dar, weil die Atmosphäre ein ,,chaotisches System" ist, d.h. kleine Unsicherheiten können zu großen Fehlern in der Vorhersage anwachsen.

Daher stützen sich heutige Methoden nicht nur auf eine einzige Vorhersage, sondern auf ein ganzes ,,Ensemble" von Vorhersagen. Das Ensemble besteht aus verschiedenen Vorhersageszenarien, den ,,Ensemble Membern". Jedes Member basiert auf einer etwas anderen, aber jeweils realistischen Konfiguration des Anfangszustands und des Vorhersagesystems. Abhängig von der aktuellen Wettersituation wirken sich diese Unterschiede auf das Vorhersageresultat aus. Typischerweise bewegen sich die Ensemble Member mit fortschreitender Vorhersagezeit auseinander. Sie vermitteln eine Vorstellung von der tagesaktuellen Vorhersagbarkeit und stellen die Basis für Wahrscheinlichkeitsaussagen dar.

Über die entsprechende API von Open-Meteo erreichen wir mit einem einzigen API-Call das Ergebnis von 20! Einzelabfrufen verschiedener Modelle.
Das schaue ich mir noch genauer an. Die API Doku sagt noch aus:

ZitatEnsemblemodelle sind eine Art von Wettervorhersagetechnik, bei der mehrere Mitglieder oder Versionen eines Modells verwendet werden, um eine Reihe möglicher Ergebnisse für eine bestimmte Vorhersage zu erzeugen. Jedes Mitglied wird mit leicht unterschiedlichen Anfangsbedingungen und/oder Modellparametern initialisiert, um Unsicherheiten und Variationen in der Atmosphäre zu berücksichtigen, was zu einer Reihe von gestörten Prognosen führt.

Durch die Kombination der gestörten Vorhersagen erzeugt das Ensemble-Modell eine Wahrscheinlichkeitsverteilung möglicher Ergebnisse, die nicht nur die wahrscheinlichste Vorhersage, sondern auch den Bereich möglicher Ergebnisse und deren Wahrscheinlichkeiten angibt. Dieser probabilistische Ansatz bietet umfassendere und genauere Vorhersageempfehlungen, insbesondere für Wetterereignisse mit großen Auswirkungen und hohen Unsicherheiten.

Verschiedene nationale Wetterdienste berechnen Ensemble-Modelle mit unterschiedlicher Auflösung der Wettervariablen und des Vorhersagezeitraums. Das ICON-Modell des Deutschen Wetterdienstes (DWD) beispielsweise bietet eine außergewöhnlich hohe Auflösung für Europa, sagt aber nur bis zu 7 Tage voraus. Das GFS-Modell kann dagegen bis zu 35 Tage vorhersagen, wenn auch mit einer geringeren Auflösung von 50 km. Welches Ensemble-Modell am besten geeignet ist, hängt vom Vorhersagehorizont und der Region ab, die von Interesse ist.
#7
Zigbee / Aw: Zigbee Switch 1 Kanal - Ni...
Letzter Beitrag von kask - 29 März 2024, 22:37:18
Darf man mal fragen warum ausdrücklich für Niederspannung?
Wieviel Last willst du schalten?

Z-Wave vlt soeiner?:
https://www.shelly.com/de/products/shop/shelly-qubino-wave-1
#8
Zigbee / Aw: Ikea SOMRIG und RODRET mit...
Letzter Beitrag von kask - 29 März 2024, 22:28:23
Ich habe die Somrig, Parasoll & Vallhorn aktiv am laufen.
Die Vallhorn funktionieren nur richtig mit AAA Akkus 1,2V. Mit Batterien kommen da sehr, sehr, seeeehr viele Fehlauslösungen.
Die Somrig funktionieren gut. Die Parasoll muß man momentan mit einer DDF selbst einbinden, funktionieren aber so erst einmal.
#9
FHEM Code changes / Revision 28725: 76_SolarForeca...
Letzter Beitrag von System - 29 März 2024, 22:10:57
Revision 28725: 76_SolarForecast: integrate the Open-Meteo API

76_SolarForecast: integrate the Open-Meteo API

Source: Revision 28725: 76_SolarForecast: integrate the Open-Meteo API
#10
ZWave / Aw: fhem und Shelly Qubino Wav...
Letzter Beitrag von rudolfkoenig - 29 März 2024, 21:38:30
Automatisch wurden 4 Geraete fuer die ZWave ID 2 angelegt, das Hauptgeraet und jeweils eins fuer die Kanaele 1, 2 und 3. (513 = 2<<8+1, usw).
Die Doku (s.u.) bezeichnet diese Kanaele als Endpoints.

Es passt fuer mich Einiges nicht:
- die zwei "Node" Geraete: FHEM legt Geraete mit dem Namen ZWave_<Klasse>_Id an. Eine Klasse <Node> ist mir nicht bekannt, und habe in den Quellen auch kein Node gefunden.
- beim automatisches Anlegen einer Endpoint-Instanz wird das classes Attribut mitangelegt, hier fehlt es.
- bei der Inklusion wird automatisch nach vclasses, zwaveplus_info und model gefragt. Ich sehe hier nur vclasses, die Antwort auf model und zwaveplus_info fehlt.

Ich gehe davon aus, dass die Inklusion nicht sauber durchgelaufen ist.

ZitatWie kann ich die beiden Kanäle unabhängig von einander schalten?
Laut https://kb.shelly.cloud/knowledge-base/wave-2pm gibt existiert das Hauptgeraet und zwei Endpoints, alle drei bieten SWITCH_BINARY (d.h. on und off) an.
Aus der Doku geht nicht hervor, welcher Kanal von wem bedient wird, deswegen rate ich: das Hauptgeraet (id 2) und Endpoint 1 (id 513) schalten Kanal 1, Endpoint 2 (id 514) schaltet Kanal 2.
Da bei der FHEM Instanz das classes Attribut fehlt, bietet FHEM kein on/off an.