[ipobserver] Channel "lastUpdatedTime" doesn't work correctly using the device "Renkforce WH2600"

[mrmerl]

ipobserver Binding in connection with Renkforce WH2600

The channel lastUpdatedTime is not reliably populated by the data source.

Expected Behavior

The value of "Receiver Time" in the web-fronted of the device Renkforce WH2600 and its assigned channel lastUpdatedTime should be identical.

Current Behavior

The channel lastUpdatedTime contains outdated data:

• webfrontend of Renkforce WH2600:

• assigned channel lastUpdatedTime:

Possible Solution

The device appears to display the day and month numbers as single digits. However, the add-on seems to expect two-digit numbers.

openhab-addons/bundles/org.openhab.binding.ipobserver/src/main/java/org/openhab/binding/ipobserver/internal/IpObserverHandler.java lines 109 onward:

                    case LAST_UPDATED_TIME:
                        try {
                            DateTimeFormatter formatter = DateTimeFormatter.ofPattern("HH:mm MM/dd/yyyy")
                                    .withZone(TimeZone.getDefault().toZoneId());

should perhaps be modified to

                    case LAST_UPDATED_TIME:
                        try {
                            DateTimeFormatter formatter = DateTimeFormatter.ofPattern("HH:mm M/d/yyyy")
                                    .withZone(TimeZone.getDefault().toZoneId());

(Remark: I tried to debug the addon by myself in Eclipse, but unfortunately I got error messages while trying to resolve the bundles. Dealing with the "astro" binding as described in the documentation was no problem; the IpObserver binding reports OSGi-errors belonging the java versions. Sorry ...)

Steps to Reproduce (for Bugs)

1. Add Renkforce WH2600 as thing and link the channel lastUpdatedTime to an item (enable "show advanced" checkmark to get the channel displayed)
2. Compare the items value with the value in the web-frontend of the device. I'm guessing the item's value in OH will be empty or differ from the web frontend of the device (as displayed above)

Context

Your Environment

• Version used: openHAB 4.1.1, ipobserver binding 4.1.1
• Operating System and version Raspbian Buster
• Renkforce WH2600 V2.2.8

[lsiepel]

Maybe you can add the binding in debug or trace logging. If we grab the actual data dat is consumed by openHAB it might be easier to fix.

[mrmerl]

With pleasure:

2024-02-22 07:58:08.598 [DEBUG] [pobserver.internal.IpObserverHandler] - Could not parse 07:58 2/22/2024 as a valid dateTime
2024-02-22 07:59:35.027 [DEBUG] [pobserver.internal.IpObserverHandler] - Finding out which units of measurement the weather station is using.
2024-02-22 07:59:35.391 [DEBUG] [pobserver.internal.IpObserverHandler] - Using metric units of measurement for temperature.
2024-02-22 07:59:35.392 [DEBUG] [pobserver.internal.IpObserverHandler] - Using metric units of measurement for rain.
2024-02-22 07:59:35.408 [DEBUG] [pobserver.internal.IpObserverHandler] - Could not parse 07:59 2/22/2024 as a valid dateTime

I tried to fix and test it by myself, but the binding seems to be unruly for me. I'm able to build "astro", also "shelly", but not "ipobserver". if it makes sense to open a new issue with the error messages of the bndtool, please let me know.

[lsiepel]

Is there some locale in the gui that can be configured and controls this format? We might need something like that to prevent regression.

What command is used and build error do you get? I use va code so not sure if I can help in that

[mrmerl]

not the date/time-format. Below you can see the settings in the gui:

Belonging the build: I'm using Eclipse, because of the recommendation in the docs. That's a part of the message:

As soon as I find time I will try vsc. I also like it more.

[lsiepel]

Sorry, don't think i can provide much help with eclipse.

Regarding the possible fix, i see multiple problems to create a reliable solution:

1. The format in your case is different to the current format in code. Is there someway we can deteect the format used? (e.g. by device, firmware version, or setting?)
2. Another issue i see in the code is that it currently uses the java timezone by TimeZone.getDefault() this may or may not be the timezone setup in the weather logger. And i'm not sure this will be fixable at all because the weather logger doe snot set the timezone, it has some 'special' way of setting timeoffset+dst.

[mrmerl]

1. IMHO: no. As far as I know, the devices are distributed under various brands. On my web interface, I don’t see any brand name. Therefore, I suspect that the GUI is the same everywhere. Perhaps, with a certain firmware version, the displayed date format has changed. However, this is purely speculation on my part. In practice, the pattern “HH:mm M/d/yyyy” should correctly scan both single and double-digit day and month numbers.
2. Correct. The binding assumes that the user sets the local time zone in the GUI. Specifically, if you change the time zone (screenshot) from 1.0 to 0.0, the displayed “Receiver Time” decreases by one hour; in the shown screenshot above, it would change from 20:09 to 19:09. (I have conducted the test.) Therefore, I do not consider the current behavior as a problem.

[lsiepel]

1. IMHO: no. As far as I know, the devices are distributed under various brands. On my web interface, I don’t see any brand name. Therefore, I suspect that the GUI is the same everywhere. Perhaps, with a certain firmware version, the displayed date format has changed. However, this is purely speculation on my part. In practice, the pattern “HH:mm M/d/yyyy” should correctly scan both single and double-digit day and month numbers.

Now it changed from MM/dd/yyyy to M/d/yyyy what if some other device or user sees dd/MM/yyyy ? The point is that we need to try to get some documentation of this API or ways to detect the format.

2. Correct. The binding assumes that the user sets the local time zone in the GUI. Specifically, if you change the time zone (screenshot) from 1.0 to 0.0, the displayed “Receiver Time” decreases by one hour; in the shown screenshot above, it would change from 20:09 to 19:09. (I have conducted the test.) Therefore, I do not consider the current behavior as a problem.

Well for others this might be an issue as the default java timezone, the openHAB timezone and the device are not allways aligned. I can understand if you want to leave this out of the scope of this issue, but looking at the code, this is an area that could be improved.

[mrmerl]

Now it changed from MM/dd/yyyy to M/d/yyyy what if some other device or user sees dd/MM/yyyy ? The point is that we need to try to get some documentation of this API or ways to detect the format.

I understand the intention completely. However, I would like to point out that the binding merely scans the webpage of an end device. Whether one can obtain any kind of documentation or release notes for such an HTML-document, I consider questionable. But it’s worth a try.

Well for others this might be an issue as the default java timezone, the openHAB timezone and the device are not allways aligned. I can understand if you want to leave this out of the scope of this issue, but looking at the code, this is an area that could be improved.

I'm with you. The HTML-elements are named timezone and dst. So the binding could "try to find out" the timezone based on these values. However, this would change the current behavior.