ITADN

[WORX] config#timestamp is already local time

#21124Closedmitch-geht-ab 创建于 2026-07-07
PR pending
M
mitch-geht-abcommented
Channel config#timestamp isn't parsed correctly, it is already local time, so item value ist now+2h (for germany) in the future. See below, log timestamp and value of item ## Expected Behavior Expect that config#timestamp is <= time of item update and not in future. ## Current Behavior See above. ## Possible Solution Could be a problem of misinterpreting `theMower.getLastUpdate());` in https://github.com/openhab/openhab-addons/blob/a5a74fd085f97d98d82fb888430dc80797fe06b2/bundles/org.openhab.binding.worxlandroid/src/main/java/org/openhab/binding/worxlandroid/internal/handler/WorxLandroidMowerHandler.java#L464 But that is just a guess. ## Steps to Reproduce (for Bugs) ``` # .items file DateTime LandroidMowerConfigTimestamp "Letztes Update" <update> {channel="worxlandroid:mower:api:steve:config#timestamp"} $ tail -f /var/log/openhab/events.log 2026-07-07 11:19:17.112 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LandroidMowerConfigTimestamp' changed from NULL to 2026-07-07T13:19:15.000+0200 (source: org.openhab.core.thing$worxlandroid:mower:api:steve:config#timestamp) ``` ## Your Environment <!-- Include as many relevant details about the environment you experienced the bug in --> * Version used: (e.g., openHAB and add-on versions) * Environment name and version (e.g. Chrome 76, Java 8, Node.js 12.9, ...): * Operating System and version (desktop or mobile, Windows 10, Raspbian Buster, ...): ``` $ dpkg -l|grep openha ii openhab 5.2.0-1 all openhab ii openhab-addons 5.2.0-1 all openhab-addons $ dpkg -l|grep jre ii zulu21-ca-jre-headless 21.0.11-3 amd64 Azul Zulu 21.50+19 (21.0.11-b10) CA Headless JRE ii zulu21-jre-headless 21.0.11-3 amd64 Azul Zulu 21.50+19 (21.0.11-b10) Headless JRE $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" ```
关闭于 2026-07-24 1 条评论