csowada / openhab2-addons Goto Github PK

After update with Openhab 2.5 from ebus-2.4.0.RC7b to ebus-2.5.1-5:
3 telegrams are listed in ebus-unresolved. To compare them the telegrams after the update, and before the update (with additional info of mapping):
In addition my exact ebus-version of the log-entries.
´´´
29.01.2020 21:48 FF 15 B5 24 06 02 00 00 00 3D 00 48 00 08 01 00 3D 00 63 0E 00 00 84 00
29.01.2020 14:10 FF 15 B5 24 06 02 00 00 00 3D 00 48 00 08 01 00 3D 00 63 0E 00 00 84 00 GET > vrc700_general.gen.solar_yield_total

29.01.2020 21:48 FF ED B5 09 03 29 3B 00 0B 00 04 3B 00 90 90 D2 00
29.01.2020 14:11 FF ED B5 09 03 29 3B 00 0B 00 04 3B 00 90 90 D2 00 GET > custom-vms02.YieldCurrentYear

29.01.2020 21:58 FF ED B5 09 03 29 56 00 E4 00 06 56 00 63 0E 00 00 6D 00
29.01.2020 14:11 FF ED B5 09 03 29 56 00 E4 00 06 56 00 63 0E 00 00 6D 00 GET > custom-vms02.YieldTotal

2020-01-29 21:48:27.748 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom configuration file 'file:///etc/openhab2/vaillant-vms02-configuration.json' ...
2020-01-29 21:48:28.530 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
2020-01-29 21:48:29.860 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - Use eBUS binding 2.5.1.202001291838 [eBUS core: 1.0.5.202001291834, eBUS configuration: 1.0.5.202001291835]
2020-01-29 21:48:29.934 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202001291834, commit: #3d1c915, build-no: #null
2020-01-29 21:48:30.008 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202001291835, commit: #3f20d94, build-no: #null

Solution

Restart openHAB

Your Environment

archlinux on Sun Java 8, ARMv7 O-Droid MC1
openHAB 2.4

Expected Behavior

After a restart of the binding all channels should be available again.

Current Behavior

From time to time the AcceptedItemType from the channel is null. In that case only a openHAB restart helps.

Source code

It happens here:

and here it is defined:

Possible Solution

Restart your openHAB server

Your Environment

archlinux on Sun Java 8, ARMv7 O-Droid MC1
openHAB 2.4

extend test CMD on ebus automatically with necessary CRC (e.g. as option).
If could also be implement show the complete telegram with answer of device on console.

As exmple on karaf console will be entered:
smarthome:ebus send "FF ED 07 04 00"
On the ebus will be send out
"FF ED 07 04 00 CC"
As result will be presented
"FF";"ED";"07 04";"00 CC 00 0A B5 56 4D 53 30 32 01 08 17 03 53 00"

The values of boiler.control.setopdata are not listed in device BAI (Openhab ->Configurations->Things).
It was present some versions ago, think in 2.4.0-RC7b was OK. As least I had mapped one value.

My investigating gave the meaning, it should be present. But somewhat is unhappy ...

The log after restart of openhab present:
2020-02-06 08:34:08.946 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
2020-02-06 08:34:12.596 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - Use eBUS binding 2.5.1.202001291838 [eBUS core: 1.0.5.202001291834, eBUS configuration: 1.0.5.202001291835]
2020-02-06 08:34:12.723 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202001291834, commit: #3d1c915, build-no: #null
2020-02-06 08:34:12.799 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202001291835, commit: #3f20d94, build-no: #null

The telegram example show it is mapped correctly:
2020-02-05 13:57:40;"10";"08";"B5 10";"09 00 00 77 FF FF FF 00 00 00 D4 00 01 01 9A 00";SET > bai.boiler.control.setopdata

And the configuration part of vaillant-bai00-configuration.json seems also be OK:
{
"label": "Operational Data from Room Controller to Burner Control Unit",
"id": "boiler.control.setopdata",
"command": "B5 10",
"set": {
"master": [
{"type": "static", "default": "00 00"},
{"name": "temp_d_lead_water", "type": "data1c", "label": "Lead water target temperature", "min": 0, "max": 100, "format":"%.1f°C"},
{"name": "temp_d_srv_water", "type": "data1c", "label": "Service water target temperature", "min": 0, "max": 100, "format":"%.1f°C"},
{"type": "static", "default": "FF FF"},
{"type": "byte", "children": [
{"name": "turnoff_water_heating", "type": "bit", "label": "Turn off water heating"},
{"type": "bit"},
{"name": "turnoffservice_water_heating", "type": "bit", "label": "Turn off service water heating"},
{"type": "bit"},
{"type": "bit"},
{"type": "bit"},
{"type": "bit"},
{"type": "bit"}
]},
{"type": "static", "default": "00 00"}
],
"slave": [
{"type": "static", "default": "01"}
]
}
},

The Telegram of B5 11 02 is landing always in ebus-unresolved.csv.
Result of check: Telegram is always a Byte longer as configured in vaillant-bai00-configuration.json and (as least in my system) always 64.
Example of an telegram:
2020-02-04 21:13:58;"10";"08";"B5 11";"01 02 8A 00 06 03 3C 96 46 8C 64 E9 00";

Adjusted configuration tested in a custom-configuration is working (added static 64):

	{
        "label":    "Operational Data of Burner Control Unit to Room Control Unit",
        "id":       "boiler.control.getopdata.02",
        "command":  "B5 11",

        "get": {
            "master": [
                {"type": "static", "default": "02"}
            ],
            "slave": [
                {"type": "static", "default": "03 3C 96 46"},
				{"name": "srv_water_target", "type": "data1c", "label": "Service water target temperature", "min": 0, "max": 100, "format":"%.1f°C"},
                {"type": "static", "default": "64"}
            ]
        }
    }

More details here:

csowada/ebus-configuration#6

linkRegistry has moved

eclipse-archived/smarthome@78f70d8#diff-87efa14fe4d7f7992108b2deedd0401e