Seite 1 von 1

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

Verfasst: 26. Jan 2022 22:15
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"}

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

Verfasst: 26. Jan 2022 23:59
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.

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

Verfasst: 27. Jan 2022 07:28
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

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

Verfasst: 27. Jan 2022 14:01
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.

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

Verfasst: 27. Jan 2022 15:58
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 :-(

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

Verfasst: 27. Jan 2022 22:39
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.

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

Verfasst: 29. Jan 2022 15:52
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.