If you want to retrieve a maximum, minimum value (since or between) from your influxdb or other DB’s you might encounter errors because you try to retrieve a Historic Items and these queries will return a combination of fields. Therefor you need to state which part you want. For the value this is easy .state
You might think the date/time can be easily solved with .getTimestamp because you see this solution in various topics for the loginfo. However this will give error 2 The solution how to solve this error is harder to find at least it was for me until I found and tried to include: .toInstant.toEpochMilli (and yes this might be verry logic for others )
The project:
I encountered these problems will trying to get data (of water usage) retrieved with an Arduino UNO with a simple homemade sketch and send over with MQTT. The majority of the logic is further inside Openhab. So it was more or less the first time I used a query like “maximumSince” inside a rule.
var your_var = DWL_liters.maximumSince(now.minusHours(vMonitor), "influxdb")
is your_item not a DateTime Item? That’s the type one should use for a timestamp like this. If it is you_item.postUpdate(your_var.getTimestamp.toString) should be sufficient if sending the ZonedDateTime has some problem for some reason. But you should be able to just send your_var.getTimestamp but only if the Item is a DateTime Item.
@rlkoshak, thanks for your reaction. I tried it straight away because it looks more straightforward. Yes my item is a DateTime item but my combination gives with the suffix “.toString” the error:
Cannot convert ‘2023-01-13T09:03:24.012+01:00[Europe/Amsterdam]’ to a state type which item ‘DWL_monitortime_max’ accepts: [DateTimeType, UnDefType].
Without any suffix:
Script execution of rule with UID ‘watermeter-1’ failed: An error occurred during the script execution: Could not invoke method: org.openhab.core.model.script.actions.BusEvent.postUpdate(org.openhab.core.items.Item,java.lang.Number) on instance: null in watermeter
My var is similar to this topic. I noticed the suffix “.toString” is not really required when using it for loginfo.
Is this a java problem which might be resolved with a newer version of Openhab?
(In the past we already discussed that using Docker is adding an extra layer of complexity)
My Item and rule files:
//==============================================================================================
DateTime DWL_monitortime_max "Verbruik (eindtijd): [%1$td/%1$tm %1$tT]" <selfruntime> (gUNO)
//==============================================================================================
rule "Reports DWL waterusage"
when
Item DWL_liters received update or // received an update of water usage
Item DWL_monitor changed // reveived new request period to monitor
then
var Number vDWL = 316490 // start value of watermeter
var Number vLITERS = 0
vLITERS = ( DWL_liters.sumSince(now.withMonth(1).withDayOfMonth(1).withYear(2023), "influxdb") )
vLITERS = ( vDWL + vLITERS ) / 1000;
DWL_meterstand.postUpdate(vLITERS)
var vMonitor = Long::parseLong(DWL_monitor.state.toString)
var vLiters_recent_tot = DWL_liters.sumSince(now.minusHours(vMonitor), "influxdb") as Number
DWL_monitor_tot.postUpdate(vLiters_recent_tot)
var vLiters_recent_max = DWL_liters.maximumSince(now.minusHours(vMonitor), "influxdb")
DWL_monitor_max.postUpdate(vLiters_recent_max.state)
DWL_monitortime_max.postUpdate(vLiters_recent_max.getTimestamp.toInstant.toEpochMilli)
//DWL_monitortime_max.postUpdate(vLiters_recent_max.getTimestamp.toString)
//DWL_monitortime_max.postUpdate(vLiters_recent_max.getTimestamp)
logInfo("diag", "Time recent max liters : " + vLiters_recent_max.getTimestamp)
end
//==============================================================================================
Possibly. there’s been some PRs which might impact this behavior in the year since OH 3.2 was released. It would be informative if this is still a problem in 3.4.
But in the mean time, your_item.postUpdate(your_var.getTimestamp.toLocalDateTime.toString) should work. The troublesome part is the timezone and that will strip the timezone off the toString.
Works will move to a newer version of Openhab to see if I can use the standard syntax.
Off topic: One thing i like of a NUC is that making a backup takes only seconds compared to the minutes on my old Pi4-2Gb. Also due to the shortage of Pi’s it looks like that in the Netherlands the secondhand prices of NUC are increasing by the month.
Migrated to 3.4.1 almost flawlessly. Inside a minute I did a pull, stop, remove and compose. The following restart of Openhab took off course a tiny bit longer. When Openhab was up and running there was only 1 problem with my DSMR meter (on USB) which I probably could have solved with a better RTFM of the troubleshooting part but solved it with the blunt-axe method (translation of a Dutch expression) of a reboot. Who cares (my girlfriend: I HAVE NO MUSIC!!!)
Anyway bottom line original problem remained and I still need to include .toLocalDateTime; Not a big deal and I forgot to mention that your examples have given me a better understanding what kind of conversion you can do for a DateTime item (so thanks for that).
? Not sure if this is a brainwave or not but could this problem be cause by an environment setting in the docker compose?: EXTRA_JAVA_OPTS: " “-Duser.timezone=Europe/Amsterdam”
No, it’s not related to anything you have control over. It’s related so to some change that was made in core somewhere that changed how date time strings are parsed. Now that I know it’s still a problem I can spend some time investigating and perhaps file an issue to make it work they way it’s supposed to.
Ok, thanks for all your good work. hereby my latest system details (including which containers i run on this system, probably overkill but perhaps helpful)
Hardware: Intel NUC 7i3BNK - 12 Gb
system: Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-58-generic x86_64)
wj4nuc@nuc:~$ docker version
Client: Docker Engine - Community
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:28:04 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.18.9
Git commit: 42c8b31
Built: Thu Dec 15 22:25:49 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.15
GitCommit: 5b842e528e99d4d4c1686467debf2bd4b88ecd86
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
wj4nuc@nuc:~$ docker exec -it openhab /bin/sh
# java -version
openjdk version "11.0.17" 2022-10-18
OpenJDK Runtime Environment Temurin-11.0.17+8 (build 11.0.17+8)
OpenJDK 64-Bit Server VM Temurin-11.0.17+8 (build 11.0.17+8, mixed mode)
wj4nuc@nuc:~$ docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
027b5d2af5f0 openhab/openhab:3.4.1 "/entrypoint bash -c…" 23 hours ago Up 2 hours (healthy) openhab
09ab78ed9d01 deconzcommunity/deconz "/start.sh" 4 weeks ago Up 2 hours (healthy) deconz
5c91cc94ebd0 pihole/pihole:latest "/s6-init" 4 weeks ago Up 2 hours (healthy) pihole
ae0afa638614 welteki/frontail-openhab:latest "docker-entrypoint.s…" 5 weeks ago Up 2 hours frontail-openhab
9a588771700c grafana/grafana-enterprise:9.3.0-ubuntu "/run.sh" 5 weeks ago Up 2 hours grafana93
05cc164fd363 influxdb:1.8 "/entrypoint.sh infl…" 6 weeks ago Up 2 hours influxdb18
c2ca81f01cc7 eclipse-mosquitto:latest "/docker-entrypoint.…" 6 weeks ago Up 2 hours mosquitto
1982589aa399 lmscommunity/logitechmediaserver:dev "start-container" 7 weeks ago Up 2 hours 0.0.0.0:3483->3483/tcp, :::3483->3483/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 0.0.0.0:9090->9090/tcp, 0.0.0.0:3483->3483/udp, :::9090->9090/tcp, :::3483->3483/udp lms
)
will move to a newer version of Openhab to see if I can use the standard syntax.