Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
Benutzeravatar
HiG
Beiträge: 136
Registriert: 16. Jun 2021 13:39
Answers: 0

Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von HiG »

Moinzen...

ich bekomme über Mqtt eine Uhrzeit als String (oder wohl genauer eine CharSequence) in der Form "08:09:00". Diese möchte ich liebendgerne in einen DateTime (oder ähnlichen) Wert überführen, um diesen gegen die aktuelle Uhrzeit auszuwerten.

Wie kann ich meine Rule anpassen, das der Wert einsprechend umgewandelt wird und ein Vergleich gegen die aktuelle Uhrzeit möglich ist? Da es sich dabei um den Sonnenaufgang handelt wäre ein ">="-Vergleich toll.
Versuch des Castings

Code: Alles auswählen

val StringItem  xxx = (I_eg_sy_as_ss as StringItem)
Mqtt-Item

Code: Alles auswählen

String   I_eg_sy_as_ss       "Sonnenuntergang"                                           { channel="mqtt:topic:ff57454363:T_eg_sy_as_01:C_eg_sy_as_01_ss"}

Benutzeravatar
udo1toni
Beiträge: 15249
Registriert: 11. Apr 2018 18:05
Answers: 243
Wohnort: Darmstadt

Re: Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von udo1toni »

Darf ich zunächst fragen, warum?

Das DateTime Item erwartet immer ein vollständiges Datum, bestehend aus Tag,Monat,Jahr, Stunde, Minute, Sekunde und Zeitzone. Über die DSL gibt es Möglichkeiten, den String entsprechend zu interpretieren und umgewandelt in ein DateTime Item zu pressen.

Aber nochmal: Warum?
Zum Einen gibt es in openHAB das astro Binding, welches unter anderem die Sonnendaten liefert.
Zum Anderen kann das astro Binding nicht nur Zeitstempel liefern, sondern auch zu definierten Zeitpunkten eine Rule triggern, also z.B. 15 Minuten nach Sonnenaufgang oder 3 Minuten vor Beginn der bürgerlichen Dämmerung, oder wenn die Sonne im Zenit steht, aber nicht vor 11:45 Uhr und nicht nach 13:05 Uhr.
Es ist also vermutlich unnötig, mit Datum und Uhrzeit zu rechnen.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet

Benutzeravatar
HiG
Beiträge: 136
Registriert: 16. Jun 2021 13:39
Answers: 0

Re: Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von HiG »

udo1toni hat geschrieben: 26. Jan 2022 23:59 Darf ich zunächst fragen, warum?
Weil es mir nicht gelungen ist dem Astro-Binding diese Dinge in der Textkonfiguration "beizubringen" #soifz

Benutzeravatar
udo1toni
Beiträge: 15249
Registriert: 11. Apr 2018 18:05
Answers: 243
Wohnort: Darmstadt

Re: Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von udo1toni »

So sieht mein manuell gesetztes Astro Thing aus:

Code: Alles auswählen

// Astro
Thing astro:sun:home "Sonne" @ "zuhause" [geolocation="49.912,8.661,130", interval=300] {
    Channels:
        Type start : civilDawn#start [
            offset=10,
            earliest="06:00",
            latest="08:00"
        ]
        Type start : civilDusk#start [
            offset=15,
            earliest="16:00",
            latest="22:00"
        ]
        Type rangeEvent : civilDawn#event  [
            offset=10,
            earliest="06:00",
            latest="08:00"
        ]
        Type rangeEvent : civilDusk#event  [
            offset=15,
            earliest="16:00",
            latest="22:00"
        ]
}
Die geolocation hat 14 Nachkommastellen, aber wer will schon wissen, wo das Regal steht, auf dem sich mein System befindet, und wo auf dem Regal das Rechner steht...

Die ersten beiden parametrierten Channel dienen der Anzeige, die beiden anderen Channel steuern die Rules an. Nicht extra angelegte Channel stehen dennoch zur Verfügung, nur halt nicht parametriert.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet

Benutzeravatar
HiG
Beiträge: 136
Registriert: 16. Jun 2021 13:39
Answers: 0

Re: Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von HiG »

udo1toni hat geschrieben: 27. Jan 2022 14:01 Die geolocation hat 14 Nachkommastellen
... und wie ich sehe...fehlt auch noch die Höhe über N.N ;-)

Dankeschön für deine Definition. Ich doktore an die erweiterten Definitionen immer noch ziemlich rum :-(

Benutzeravatar
udo1toni
Beiträge: 15249
Registriert: 11. Apr 2018 18:05
Answers: 243
Wohnort: Darmstadt

Re: Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von udo1toni »

Die Things folgen alle dem selben Schema. Natürlich unterscheiden sich die Namen der Parameter (und deren Funktion) teilweise erheblich, da diese ja vom abgebildeten System abhängen.
Aber grundsätzlich: Gibt es einen Bus, so gibt es in openHAB eine Bridge, die den Kontakt zu dem Bus herstellt.
(Der Begriff "Bus" ist dabei aber weit gefasst... z.B. unterstützen Yamaha Receiver teilweise mehrere Zonen. Im Binding werden die Zonen als Things abgebildet und der Verstärker als Ganzes ist die Bridge. Letztlich geht es um eine zweistufige Hierarchie, das übergeordnete ist die Bridge, darunter folgen Things, die die Bridge zur Komunikation benötigen.)
Unterhalb der Bridge gibt es dann die Things, wobei ein Thing einem Gerät entspricht
(auch wenn das teilweise nicht zwingend ist, sollte man diesem Prinzip folgen... also z.B. nicht den mqtt "Bus" als ein großes Gerät mit zig Channels betrachten, sondern jedes Gerät, welches per mqtt mit openHAB kommuniziert, als einzelnes Thing anlegen.)
Üblicherweise wird man alle Things, die zu einer Bridge gehören, als Tochterelemente anlegen, also innerhalb der geschweiften Klammern, welche der Bridge folgen.
Genauso sind die Channel eines Things innerhalb der geschweiften Klammern des Things verortet. Die Schlüsselworte Bridge, Thing und Channels könnten sogar entfallen (aber es hilft. die Definition später zu verstehen). Die Parameter der entsprechenden Sektion kommen in [], Parameternamen stehen ohne Anführungszeichen, der Wert steht in Anführungszeichen, sobald es sich um einen String handelt, Zahlen stehen gewöhnlich ohne Anführungszeichen. Die einzelnen Parameter sind durch Komma voneinander getrennt.
Bridge und Thing (soweit das Thing keiner Bridge zugeordnet ist!) werden durch das Binding, den Typ und die ID definiert, also z.B. astro:sun:home, astro ist das Binding, sun ist der Thingtyp und home ist der vergebene Name, mit dem das Thing angesprochen wird. Danach folgt das Label, welches in der Auflistung der Things verwendet wird. nach dem optionalen @ folgt noch die Location für openHAB2, dieser Teil ist in openHAB3 obsolet (löst aber keinen Fehler aus, falls vorhanden).

Wenn ein Thing einer Bridge zugeordnet ist, entfällt die Angabe des Bindings, dies ergibt sich ja zwingend aus der Bridge. Deshalb steht dann auchkein Doppelpunkt zwischen Typ und Name des Things.
Man kann Things, die zu eijner Bridge gehören allerdings auch losgelöst von der Bridge anlegen, dann sind es wieder Things "ohne" Bridgezuordnung (weil die Zuordnung erst innerhalb der Definition erfolgt.) Die UID der Bridge wird in () hinter der UID des Thing geschrieben. Hierarchisch so::

Code: Alles auswählen

Bridge hue:bridge:mybridge [ ipAddress="192.168.3.123" ] {
 Thing 0210 bulb1 [ lightId="1" ]
 Thing 0210 bulb2 [ lightId="2" ]
}
Getrennt so:

Code: Alles auswählen

Bridge hue:bridge:mybridge [ ipAddress="192.168.3.123" ]

Thing hue:0210:mybridge:bulb1 "Label" (hue:bridge:mybridge) @ "Location" [lightId="1"]
Thing hue:0210:mybridge:bulb2 "Label" (hue:bridge:mybridge) @ "Location" [lightId="2"]
Vorteil der zweiten Version ist, dass Bridge und Thing nicht zwingend in der selben Datei definiert sein müssen.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet

Benutzeravatar
HiG
Beiträge: 136
Registriert: 16. Jun 2021 13:39
Answers: 0

Re: Could not invoke method: java.time.LocalDateTime.parse(java.lang.CharSequence)

Beitrag von HiG »

udo1toni hat geschrieben: 27. Jan 2022 22:39 Vorteil der zweiten Version ist, dass Bridge und Thing nicht zwingend in der selben Datei definiert sein müssen.
Ich nutze -ausser für Mqtt- auch die zweite Version.

Antworten