[resol] New binding in OH3.3 does not work with device SKSR 1/2/3

[paicl01]

Expected Behavior

I have used the previous version of the RESOL binding
(https://github.com/wborn/openhab-addons/releases/download/resol-20201215/org.openhab.binding.resol-3.0.0-SNAPSHOT.jar)
without issues.

After upgrade OH3.0 --> OH3.3 the RESOL binding is now officially included and I changed to the new binding.
I expected that the new binding would work as the previous one.

Current Behavior

The KM1 is recognized by the new binding, and a new thing SKSR 1/2/3 is found in the inbox, which goes online without error. However, after connecting the existing or new items to the channels of this new thing, they are not updated.
I dont know how to proceed.

Possible Solution

Steps to Reproduce (for Bugs)

Context

Your Environment

• 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, ...):

[paicl01]

Edit:
I did several loops of clear-cache and restarts of openhab.
It turns out that the items are filled once with the value present at startup. After this, they stay at this value and are never actuated.

[BillGOH]

KM1 working fine here with the binding since openHAB 3.2. It controls a Remacal device.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/resol-vbus-channels-not-updated/129591/13

[ramack]

Did you delete all things that were created with earlier versions and recreated them? - I have no idea why that should help, but maybe its worth a try.

I have OH3.3 running smoothly with the resol binding.

And for debugging it would be great if you could enable trace logging for the resol binding by adding
<logger name="org.openhab.binding.resol" level="INFO" />
into log4j2.xml and check your logs for details or paste it here or there.

[paicl01]

I added your proposed line to the log entries, this now looks as follows:
`openhab> Log:get
Logger │ Level

ROOT │ WARN
javax.jmdns │ ERROR
javax.mail │ ERROR
openhab.event │ WARN
openhab.event.AddonEvent │ ERROR
openhab.event.InboxUpdatedEvent │ ERROR
openhab.event.ItemAddedEvent │ ERROR
openhab.event.ItemChannelLinkAddedEvent │ ERROR
openhab.event.ItemChannelLinkRemovedEvent │ ERROR
openhab.event.ItemRemovedEvent │ ERROR
openhab.event.ItemStateEvent │ ERROR
openhab.event.RuleAddedEvent │ ERROR
openhab.event.RuleRemovedEvent │ ERROR
openhab.event.RuleStatusInfoEvent │ ERROR
openhab.event.StartlevelEvent │ ERROR
openhab.event.ThingAddedEvent │ ERROR
openhab.event.ThingRemovedEvent │ ERROR
openhab.event.ThingStatusInfoEvent │ ERROR
openhab.event.ThingUpdatedEvent │ ERROR
org.apache.cxf.jaxrs.sse.SseEventSinkImpl │ ERROR
org.apache.karaf.jaas.modules.audit │ INFO
org.apache.karaf.kar.internal.KarServiceImpl │ ERROR
org.apache.karaf.shell.ssh.SshUtils │ ERROR
org.apache.karaf.shell.support │ OFF
org.apache.sshd │ WARN
org.eclipse.lsp4j │ OFF
org.jupnp │ ERROR
org.openhab │ INFO
org.openhab.binding.resol │ INFO
org.ops4j.pax.url.mvn.internal.AetherBasedResolver │ ERROR
org.ops4j.pax.web.pax-web-runtime │ OFF
su.litvak.chromecast.api.v2.Channel │ ERROR`

As mentioned, I can update the channels by disabling and enabling the VLAN bridge in the status line, and get new values in the items immediately.

However, no log entry at all shows up in log viewer screen is related to the binding.
Are there other log settings necessary to see anything?
Thank you for your help.

[ramack]

Ah sorry, I wrote INFO, but meant TRACE. Could you change it once more? - With trace logging you should see every VBUS packet in the logs, so at least when you do the "disabling and enabling the VBUSLAN bridge" there should be some entries...

[paicl01]

so nowI changed the log to TRACE and after going from offline to online, the output is as shown in the first scrreenshot.
No more messages after this initial one.

With your advice, I went back to an old backup system with OH3.01 and the marketplace version of the binding.
With this configuration I get the channel trace message once every second, as shown in the second screen shot.
But interestingly, there is an additional line at the bottom, which give a hint that this KM1 device has another channel "system_time2", which does not show up in the new version.
Don't know if this could cause the trouble?

[ramack]

Yes, I think this is a good indication! Obviously there is a problem while interpreting systemtime2 - there are some special cases for different types. I have to dig into the code for that...

If you spot the full logfile: is there no exception shown after the Systemzeit message?

[paicl01]

No, I do not see any exception message.
it seems in the old binding the problem is recognized and ignored, in the new binding communication is stopped.

Thanks for your efforts.

[ramack]

@danielwippermann can you explain the packet 00_0010_7210_10_0100_042_2_0_1 ? According to http://danielwippermann.github.io/resol-vbus/#/vsf/fields/00_0010_7210_10_0100 it doesn't exist 😄

Is it a second interpretation of the 00_0010_7210_10_0100_042_2_0 to include the weekday?

Is the "Systemzeit2" for getPacketFieldSpec().getType() of type WeekTime (SpecificationFile.Type)?

My impression is, that in ResolThingHandler.java#L275 we fail to interpret the time format. Maybe in line 70 there is a wrong format for WEEK_FORMAT and it should be EEE,HH:mm (as WEEKTIME_FORMAT_STRING) instead?

[paicl01]

would it help if you can access my device from external and check the output directly ?
If yes, I could open it on port 7053 on my reverse proxy list.

[ramack]

Thanks for the offer, I was thinking to ask for that, but first I need to get my dev environment running again - as I do not regularly contribute to openHAB usually nothing works when I restart the activities for things like that. I will try to change what I suspect that could work and publish a .jar of the binding for trial. If that doesn't solve the issue I would come back to you about a direct access to you system.

[ramack]

ok, it was a bit challenging and I did not try it the jars myself but here is one for OH3.1 and another one for 3.4(pre) I hope one of them is working in your OH3.3 environment. Would be great if you could try replacing the resol-binding jar from your distribution by one of these (preferable the 3.4 one) and paste a trace log...

[paicl01]

short report of my testing of your new bindings:

• both versions go nominally into active state:
  3.4: same behavior as the old one, no update of values after startup, and no update after restart. Channel system time is present, but stays NULL
  3.1: update of values is working (updates every second, which is far too much for me, could this be adjusted?). There is no error message any more in the message block about system time2, and there is no channel for system time at all in the thing channel list.

Log files for both versions:
openhab31.log
openhab34.log
events31.log
events34.log

For me, the 3.1 thing does its job and I don't need the time channel. But of course, it would be good to have the issue solved at the root, and a binding for the correct setup fulfilling OH3.4 conventions would be available.
I appreciate your help, than you

[ramack]

Sorry for the long response time, I don't catch the problem in this case. May I come back to your offer to check with your device and you share the connection details with me (privately)?

[danielwippermann]

Sorry for the late reply.

@danielwippermann can you explain the packet 00_0010_7210_10_0100_042_2_0_1 ? According to http://danielwippermann.github.io/resol-vbus/#/vsf/fields/00_0010_7210_10_0100 it doesn't exist 😄
Is it a second interpretation of the 00_0010_7210_10_0100_042_2_0 to include the weekday?

Yeah, correct. We cleaned up some VBus specs in January 2021, most fixing typos, but also deleting that duplicate "Systemzeit2" field in the SKSR spec. Before that there were two fields interpreting the same byte sequence (hence the _1 suffix at the end to create a unique ID) which only differed in their format and range.

The first, older interpretation back then (without the "_1" suffix) only contained time-of-day ranging from 0 to 1439 and wrapping around to 0 again. Later the controller's firmware was changed to also include the weekday, resulting in the value ranging from 0 to 10079 before wrapping back to 0. But instead of replacing the previous field in the VBus spec an additional field was added, using the same byte sequency and hence having a similar ID.

During said cleanup in January 2021 I removed the first, older representation in favor of the newer one. Now the time-of-weekday variant is the default and the additional "_1" is gone. If the controller's firmware still sends only a range between 0 and 1439, it will always display as Monday :)

Is the "Systemzeit2" for getPacketFieldSpec().getType() of type WeekTime (SpecificationFile.Type)?

Yes, it is of Type "WeekTime" now (at least in the most current VSF versions).

[ramack]

No problem for the timing. Your answers are always of a quality that justify some waiting 😄

Anyhow, I think your answers fit to what I changed now, and the only point is to get this into the main repo, thanks a lot!

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/resol-vbus-channels-not-updated/129591/17