Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Kann man die Zeitzone dann nicht eigentlich als Offset von UTC und Buszeit berechnen ohne sie explizit angeben zu müssen? Damit würde das Logikmodul in allen Zeitzonen funktionieren.
Das verstehe ich nicht... Zeitzonen sind doch ein Offset? Man muss ja was angeben. Und da Du ja selber bauen musst, könntest Du das ja so abändern, dass es auch in Neuseeland läuft.
Ich hab das Coding für die Sonnenstandsberechnungen nur kopiert, nicht selber erstellt. Ich kann nicht sagen, ob es außerhalb der 4 Zeitzonen funktioniert. Aber wenn das jemand an die gesamte Welt anpasst, nehme ich gerne Pull-Requests entgegen.
Das verstehe ich nicht... Zeitzonen sind doch ein Offset? Man muss ja was angeben. Und da Du ja selber bauen musst, könntest Du das ja so abändern, dass es auch in Neuseeland läuft.
Ja, war natürlich von mir im Kreis gedacht und Mist. Das Modul hat ja nur die Buszeit und du musst natürlich den UTC Offset wissen. Hatte meinen Post auch schon geändert. Da haben wir uns gekreuzt.
Ich hab das Coding für die Sonnenstandsberechnungen nur kopiert, nicht selber erstellt. Ich kann nicht sagen, ob es außerhalb der 4 Zeitzonen funktioniert. Aber wenn das jemand an die gesamte Welt anpasst, nehme ich gerne Pull-Requests entgegen.
Ich habe bei mir erstmal im Quellcode den Offset fix vorgegeben und experimentiere mal etwas. Langfristig wäre es natürlich schon besser wenn man es über die ETS vorgibt. Ich schau mal ob ich mich da ausreichend einarbeiten kann.
Wenn Du Dir sicher bist, das der Algorithmus für Sonnenstrand vernünftig funktioniert und du das passend getestet hast, kann ich gerne auch den Parameter in die ETS einfügen. Das bekomme ich schnell hin. Mir ging es eher um Korrekturen im Coding und passende Tests...
Wenn Du Dir sicher bist, das der Algorithmus für Sonnenstrand vernünftig funktioniert und du das passend getestet hast, kann ich gerne auch den Parameter in die ETS einfügen. Das bekomme ich schnell hin. Mir ging es eher um Korrekturen im Coding und passende Tests...
Super und vielen Dank für das Angebot. Ich teste erstmal eine Zeit lang und melde mich dann. Da ich den Offset im Quellcode erst mal setzen kann, ist da nicht so die Eile. Sicher kein Anlass nur dafür die knxprod zu ändern. Kann man mal bei einem anderen Release mit rein nehmen.
Ich habe mir eben das PM+LOG Big 1.5 release installiert und bin evtl wieder in einen Bug gelaufen.
Hi, ich habe den Fix hierzu jetzt auf github (auf main). Ein Release kann ich aber frühestens in der ersten Januar-Woche machen. Nur falls Du Dir das vorher ziehen und selber bauen willst.
Ich habe mir mal die Appikation in ETS geladen und in der Anleitung gestöbert.
ist es mit dem hier verwendeten Controller möglich, remanente Eingänge zu nutzen? Falls ja, in welchem Umfang?
Ich habe hierzu leider nichts direkt gefunden und die Ableitung erwähnt (zu Recht), dass dies abhängig von der verwendeten Hardware ist.
Seit gestern ist bei uns Wasser abgeschaltet worden und wie immer macht man sich dann Gedanken um Wasser- oder Stromausfall. Da ich keine USV habe, würde ich halt gerne ein paar Werte retten, damit nicht alles wild schaltet
Viele Grüße
Nils
EDIT:
aber gerade in einem anderen Thread die Frage beantworten können:
"Das speichern der Eingangs-KO im nichtflüchtigen Speicher geht jetzt auf allen Prozessoren (SAMD und RP2040)." https://knx-user-forum.de/forum/proj...08#post1829508
"Das speichern der Eingangs-KO im nichtflüchtigen Speicher geht jetzt auf allen Prozessoren (SAMD und RP2040)."
Wenn Du das nutzen willst, solltest Du auf den RP2040 gehen (PiPico), der ist neuer und moderner. Je nachdem, welche Bedeutung die geretteten Werte für Dich haben, solltest Du folgendes wissen:
Die Werte werden beim Stromausfall, beim Neuprogrammieren oder beim Neustart über die ETS gespeichert und stehen nach einem Neustart zur Verfügung
Ein Reset (Taste am Gerät) oder gleichartiges Verhalten (z.B. Watchdog) speichert die Werte nicht.
Eine neuere Firmware-Version kann die Werte auch löschen. Beim SAMD passiert das immer, beim RP2040 normalerweise nicht. Ich sage normalerweie, da sich theoretisch das Speicherlayout in Zukunft ändern könnte, dann würde das doch passieren. Aber das wird dann auch in der Applikationsbeschreibung stehen.
Man kann bei jedem KO, das seine Werte im nichtflüchtigen Speicher ablegt, auch angeben, welchen Zustand es annehmen soll, wenn kein Wert im Speicher existiert, um auch im Lösch-Fall einen vernünftigen Startup zu erlauben.
Nur "Expectation Management". Ist für so was wie z.B. Zählerwerte nicht wirklich geeignet.
vielen Dank für die ausführliche Antwort. Mein Plan wäre, einige Zustände wieder richtig auf die Reihe zu bekommen, hauptsächlich bei Spannungsausfall.
An- und Anwesenheit, Nachtmodus (gesperrtes Licht) oder ist Sommer oder Winter? Heizung möglichst nicht im Winter ab- oder im Sommer anschalten. Bei Fernwärme muss die Heizung nicht erst anfahren, es müssen lediglich Ventile geregelt werden.
Halt ein geordneter Zustand nach Spannungswiederkehr. Teils möglichst direkt und teils wäre auch 30-60 min. Später okay, wenn es automatisch passiert.
Applikation programmieren, Firmware aktualisieren oder ähnliches sind Dinge, wo ich anwesend bin. Dann muss ich halt zur Not selber ein paar Zustände lesen oder schreiben.
Wenn also etwas unerwartetes passieren sollte (Stromausfall), möchte ich versuchen möglichst automatisch in den dann gültigen Sollzustand zu kommen. Das ist der Plan.
Ich speicher Sommer/Winter bei mir genau so im Logikmodul ab.
Setzen tu es ich das über Home Assistant, das Logikmodul speichert den Wert und andere Geräte können den bei Neustart dann abrufen.
So sieht das der Kanal bei mir aus: grafik.png grafik.png grafik.png grafik.png
Wichtig ist bei dem Ausgangs KO das Ü Flag zu entfernen damit der Kanal nur auf ReadRequests antwortet.
Du kannst auch beim Eingang das L-Flag setzen und so den Wert speichern/abrufen.
Der Vorteil ist, das Du dadurch jeden DPT speichern kannst, den die Eingänge unterstützen.
Stimmt. Das war zu einfach und ist mir nicht eingefallen
Was Du gemacht hast, ist trotzdem ein gutes Beispiel. Deine Lösung ist die flexibelste und bietet die meisten Möglichkeiten. Der spezielle Fall, den Du hier nutzt, geht mit dem Vorschlag von willisurf einfacher. Was bei Dir aber möglich ist:
Empfang des zu speichernden Wertes und Senden können auf 2 GA liegen (z.B. Empfang ist Status, gesendet werden soll aber immer als Schaltsignal
Du kannst das Senden verzögern
Du kannst es auch mit dem Ü-Flag nutzen, um auch KO auf einen Wert zu setzen, die selber nicht lesen können
Natürlich kann man auch mit Deiner Lösung jeden DPT nutzen
Du könntest sogar noch DPT-Konvertierung machen
Mit einem kompletten Logikkanal kann man die Einschaltsituation sehr detailliert beeinflussen, die Lösung von willisurf ist immer gut geeignet, wenn man direkt 1:1 den Wert nutzen will.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar