Openhab 2.5 - Openweathermap startet

[peter-pan]

Ich nutze die Paper UI um Addons zu installieren

Genau diese Variante nutze ich in der Regel auch, ausser Homematic. Da habe ich Bridge/Things auch über PaperUi/Autodiscovery angelegt und die Items dann über VSCode als Text-File generiert.

Mittelfristig wirst Du an dieser Stelle umdenken müssen denn mit OH3 wird die Textkonfiguration sich erheblich ändern. Aber dann fällt auch das Kuddelmuddel weg, denn die Änderungen in der UI werden dann auch im Textfile sichtbar sein. (Also, wenn es wie geplant läuft, natürlich...)

.
Das wäre toll, wenn das klappen würde.

[Tokamak]

Mittelfristig wirst Du an dieser Stelle umdenken müssen denn mit OH3 wird die Textkonfiguration sich erheblich ändern.

Derzeit stelle ich unter OH2.5 alles komplett auf Python um, um echt programmieren zu können, was mit der Rules-DSL einfach nicht geht. Für mich dürfte OH3 größeren Einfluss auf die Next Rule Engine haben als die Umstellung der Konfiguration.

Was ich bisher nicht gefunden habe, ist eine Aussage, wann überhaupt mit OH3 zu rechnen ist. Gibt es da schon grobe Schätzungen?

[udo1toni]

Derzeit stelle ich unter OH2.5 alles komplett auf Python um, um echt programmieren zu können, was mit der Rules-DSL einfach nicht geht. Für mich dürfte OH3 größeren Einfluss auf die Next Rule Engine haben als die Umstellung der Konfiguration.

Was ich bisher nicht gefunden habe, ist eine Aussage, wann überhaupt mit OH3 zu rechnen ist. Gibt es da schon grobe Schätzungen?

Der Punkt ist, dass die Rules DSL zumindest in OH3.0.0 noch unterstützt wird, aber die Unterstützung für .items und .things Dateien wird nicht mehr vorhanden sein, ebenso wie es keine Unterstützung für OH1-Bindings mehr geben wird.

Es gibt bereits die Möglichkeit, sich die Beta zu installieren (ich hab das mal in Docker laufen lassen, da ist es vermutlich am bequemsten). Wenn alles gut läuft, könnte ich mir Dezember '20 durchaus als realistisch vorstellen (der Dezember hat Tradition...)
Man sollte das aber nicht überbewerten, denn Niemand ist gezwungen, sofort umzusteigen.

Was das "richtig" programmieren betrifft, kann ich das ehrlich gesagt nicht verstehen. Es mag Dinge geben, die mit der Rules DSL nur schwer realisierbar sind, bzw. die mit Jython wesentlich eleganter gelöst werden können, aber bisher habe ich noch für jedes Problem eine Lösung gefunden.
Man sollte an dieser Stelle auch nicht vergessen, dass oftmals schon die Aufgabenstellung zu hinterfragen ist.
Manchmal kann man durch Umformulierung des Problems eine wesentlich elegantere Lösung finden, die schließlich zum gleichen Ergebnis führt, z.B. statt eine Funktion zu nutzen, damit man einen großen Codeblock nicht für x Items wiederholt eingeben muss, die Items gruppieren und geschickt benennen, so dass man mit einer generalisierten Rule auskommt, die die Gruppe verwendet. Habe ich bei mir und auch für Andere schon oft gemacht...

[Tokamak]

Als Entwickler löse ich die Probleme lieber grundsätzlich, einfach, weil es mir Spaß macht.
Die Rules-DSL zwingt einem eine prozedurale Entwicklung auf. Da sie keine Klassen und (Helper-)Funktionen ermöglicht, musste ich mit ihr viele Klimmzüge machen - an einer Stelle eine Hashmap von Pairs von Arrays von Items und Arrays von Integers etwa, wo der Einsatz von Klassen um Größenordnungen einfacher gewesen wäre - und hatte trotz Nutzung von Concurrent-Klassen immer wieder mal Probleme, die ich nicht gelöst bekam.

Mit Python läuft das wie geschnitten Brot. Dort habe ich mir eine eigene Timer-Klassen geschrieben, die sowohl createTimer() als auch Quartz (Time cron) ersetzt, Periodizität beherrscht, über Switch-Items ein- und ausgeschaltet und bei Bedarf durch DateTime-Items gesteuert werden können ("starte jeden Tag zum 'Sonnenaufgang - 17,2 Minuten' " ist damit nur eine Zeile Code). Mit Python nutze ich OH selbst nur noch zur Information über Items- und Kanal-Ereignisse, wofür ich mir einen eigenen Wrapper geschrieben habe.
Das ist aber nichts, von dem ich irgendjemanden überzeugen will. Ich wollte einfach Python lernen und fand in OH eine praktische Anwendung.

Wenn es keine Things- und Items-Dateien mehr geben soll, soll dann alles über PaperUI - oder einen Nachfolger - konfiguriert werden? Das würde mir gar nicht behagen.
Wo finde ich Informationen darüber?

[peter-pan]

Unterstützung für .items und .things Dateien wird nicht mehr vorhanden sein

... das hab ich jetzt noch nicht so ganz verstanden. Ich dachte es gibt den Textfiles, die auch per UI verändert werden können !? (Schade).

Also ob programmieren oder scripten oder codieren oder "whatever". Für mich ist das alles das Gleiche. Das Gleiche gilt auch für die Programiersprachen, ob Assembler, Cobol, Basic, Python, Rules DSL, Bash, oder, oder, oder.... Für mich sind das alles Programmiersprachen, ... mit Vorzügen und Nachteilen, je nach dem was man gerade lösen will. Ich nehme ja auch keinen LKW, wenn ich einen Sack Sand vom Auto in den Garten transportieren will, da reich auch ein Schubkarren. . Vielleicht liegt es auch daran, dass ich das nicht gelernt habe, sondern sozusagen aus der "Amateur-Brille" sehe

Ich habe auch ein Testsystem laufen, das komplett auf die DSL-Rules verzichtet und nur noch mit JSR223/Jython-Scripts läuft und was das selbe macht wie mein Produktiv-System. Postiv sind hier die "Comprehensions" anstelle von Lambdas. Negativ finde ich, dass man für Alles und Jedes eine Bibliothek oder Funktion importieren muss (kann man natürlich auch postive sehen). Das Ist mit Rules-DSL doch einfacher und da gehe ich mit Udo einig

Manchmal kann man durch Umformulierung des Problems eine wesentlich elegantere Lösung finden, die schließlich zum gleichen Ergebnis führt, z.B. statt eine Funktion zu nutzen

auch wenn ich mich manchmal damit schwer tue "logisch" zu denken . Aber dafür gibt's ja das Forum.

Gruss - Peter

[peter-pan]

Mit Python läuft das wie geschnitten Brot. Dort habe ich mir eine eigene Timer-Klassen geschrieben, die sowohl createTimer() als auch Quartz (Time cron) ersetzt, Periodizität beherrscht, über Switch-Items ein- und ausgeschaltet und bei Bedarf durch DateTime-Items gesteuert werden können ("starte jeden Tag zum 'Sonnenaufgang - 17,2 Minuten' " ist damit nur eine Zeile Code). Mit Python nutze ich OH selbst nur noch zur Information über Items- und Kanal-Ereignisse, wofür ich mir einen eigenen Wrapper geschrieben habe.

Das hört sich ja toll an (für mich aber zu hoch). Wäre es da nicht sinnvoll, wenn du dich mit Scott Rushworth (5iver) aus dem internationalen Forum in Verbindung setzen würdest ? Vielleicht können deine Klassen, etc. ja in die Helper Libraries aufgenommen werden.

[Tokamak]

Nunja, die Klasse "PlannedTimer" benötigt meine Rule-Wapper-Klasse "OHRule", damit sie auf die DateTime- und Switch-Items reagieren kann.

Um die Datetime-Klasse von Python anstelle von DateTime bzw. ZonedDateTime von OH nutzen zu können, benötige ich für den "Time Cron"-Ersatz die Umwandlung vom naiven Datetime in ein Datetime mit Zonen, wofür ich pytz verwende (Hintergrund: Jeden Tag um 4 Uhr ist normalerweise "alle 24 Stunden", außer bei der Zeitumstellung).

Soll heißen, wer meine Timerklasse verwenden will, muss pytz installieren - das ist einfach - und auch OHRule haben.

Wenn du Interesse hast, stelle ich das gerne zur Verfügung.

[peter-pan]

Wenn du Interesse hast, stelle ich das gerne zur Verfügung.

...neee, neee, das ist zwar lieb von dir, aber wie gesagt, ich bin nur Dummy/Enduser. Aber Entwickler wie du es einer bist, sollten sich doch untereinander austauschen und die OH-Gemeinde sucht immer gute Leute, die sich da mit einbringen können (glaube ich jedenfalls).

[udo1toni]

Unterstützung für .items und .things Dateien wird nicht mehr vorhanden sein

... das hab ich jetzt noch nicht so ganz verstanden. Ich dachte es gibt den Textfiles, die auch per UI verändert werden können !?

Ja, aber es wird weder .items noch .things Dateien in der jetzigen Form geben. Xtext fliegt raus, und das ist die Grundlage für .items und .things.
Soweit ich das mitverfolgt habe, wird das Format in Richtung json gehen, aber das ist schon eine ganze Weile her, yaml war auch schon im Gespräch.

Was das Programmieren betrifft, ich bin auch kein Programmierer. Ich kann ein bisschen was zusammentippen, habe aber nie gelernt, wie man "professionell" programmiert.

[wolfii]

Servus, ich hab das openweathermap Binding um Zugriff auf die One Call API erweitert und suche noch ein paar Tester. Details siehe hier:

https://github.com/openhab/openhab-addons/issues/7308

Danke und viele Grüße

Wolfgang