New openHab2 EnOcean binding

[fruggy83 (Daniel Weber)]

Hi @Bize
the PR regarding the EEP D2-50 just got merged today. I would be happy if you could test it.

@Ratiomatic
I will create the PR regarding SMACK in the next days and EEP D2-11 afterwards.

[dirkdirk (Dirk)]

Hello @fruggy83
it would be nice if you could find some time to give me short feedback regarding my posts:

New openHab2 EnOcean binding

Hey, is anyone here using a room operating panel? I am missing the humidity channel with the EEP: A5-10-12. There should be a humidity channel, but there isn’t one. Any ideas how to add the channel? Thank you! [missing_channel]

New openHab2 EnOcean binding

Hey Daniel @fruggy83, Merry Christmas! I opened a issue at the repo regarding the state pattern. I don’t know why, but at the moment the Fabh61 is working fine. Motion and lux are both working, so you don’t need to waste your time and check on that issue. Edit1: Issue already solved! Edit2: It would be nice if you could implement the FUTH65D for setpoint like via gfvs (and the F4HK14 for checking the state). So it would be possible for me to control my heating via this binding. [image] […

Thank you!

Best regards
Dirk

[Bize]

Hi Daniel (@fruggy83),

i already tried it, but i was not succesfull.
First I updated OH by openhabian-config and then i installed the enocean binding via paper UI (version 2.5.12).
Also i tried to update the enocean bundle in Karaf.

For me it seems like, the binding didn’t change. How can I update it?

Thank you!

[fruggy83 (Daniel Weber)]

Hi @Bize,

you first have to upgrade to OH 3 snapshot. I have not migrated it back to 2.5.

Best regards
Daniel

[Bize]

Hi @fruggy83,

now with OH3, i can find the device (D2-50 ventilation device) only as generic device (same as with OH2). In the Thing settings it is still mentioned: “eep = D2_FF_FF” and Thing type: “Thing whose EEP is unsupported. Use a TRANSFORM to convert things messages.”

When i now link all the available channels, like rollershutter → there is no effect to the device. But: the only thing what it seems to receive is the RSSI signal strength value.

For me it looks like the D2-50 is not available. I also can’t manually add it when I want to add a new Thing.

Any ideas?

BR
Berti

[fruggy83 (Daniel Weber)]

Hi Berti @Bize,

sorry for the misunderstanding. You have to use the OH 3.1 snapshot to be able to use the D2-50 EEP. I just released a new version of the openocean binding right now. So you also could just use this release. Uninstall the official enocean binding and copy the openocean.jar into your addon folder.

Best regards
Daniel

[Bize]

Hi Daniel, (@fruggy83)

ok thank you! I tried now your provided snapshot - thanks a lot for this!
Binding was found from openhab3.

But still not really working:

• It doesn’t find the device when i “SCAN” for it and try to pair. This - by the way - was at least successful under OH2.5 That means in my eyes → from the device side, the pairing should be working.
• Then I tried to “Add manually” the device.
  First problem was, to get the “EnOceanId”. Furtunately from OH2.5 - as mentioned above - I could get this Id. With this I could pair the device. It seems to be “online”.
  Nevertheless so far the device seems not to be paired (displayed at the device). Furthermore via the channel Direct Operation Mode Control I had no success to change the device’s operation mode.
• Also the other channels like fan speed or air temperature just give back NULL.

The Logger shows me the following:

2021-02-25 22:43:47.286 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Received teach in message from 050D3E63

2021-02-25 22:43:47.288 [INFO ] [covery.EnOceanDeviceDiscoveryService] - EnOcean Package discovered, RORG UTE, payload D480FF61000050D2050D3E6300, additional 00FFFFFFFF4100

2021-02-25 22:43:47.289 [ERROR] [ding.enocean.internal.eep.EEPFactory] - Cannot instantiate EEP D2-50-00: null

2021-02-25 22:43:47.291 [ERROR] [ernal.transceiver.EnOceanTransceiver] - Exception in informListeners
(...)
2021-02-25 23:00:52.198 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 1

2021-02-25 23:00:52.212 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 1

2021-02-25 23:00:52.229 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 3 to 1

2021-02-25 23:00:54.691 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 2

2021-02-25 23:00:54.698 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 2

2021-02-25 23:00:54.712 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 1 to 2

2021-02-25 23:00:56.249 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 4

2021-02-25 23:00:56.256 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 4

2021-02-25 23:00:56.267 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 2 to 4

2021-02-25 23:00:57.990 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 11

2021-02-25 23:00:57.995 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 11

2021-02-25 23:00:58.008 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 4 to 11

2021-02-25 23:01:00.866 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 1

2021-02-25 23:01:00.870 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 1

2021-02-25 23:01:00.882 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 11 to 1

2021-02-25 23:01:03.341 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 2

2021-02-25 23:01:03.345 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 2

2021-02-25 23:01:03.355 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 1 to 2

2021-02-25 23:01:05.935 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 4

2021-02-25 23:01:05.941 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 4

2021-02-25 23:01:05.954 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 2 to 4

2021-02-25 23:01:07.765 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 4

2021-02-25 23:01:07.770 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 4

2021-02-25 23:01:10.242 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LuefterEG_DirectOperationModeControl' received command 13

2021-02-25 23:01:10.246 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LuefterEG_DirectOperationModeControl' predicted to become 13

2021-02-25 23:01:10.256 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LuefterEG_DirectOperationModeControl' changed from 4 to 13

So far I have no idea how to go on.
I think, the problem is, that the pairing doesn’t run properly. What do you think?

Thanks & Greetings,
Berti

[fruggy83 (Daniel Weber)]

Hi Berti @Bize ,

indeed the pairing does not work. It seems as if the teach in message cannot be handled correctly: Cannot instantiate EEP D2-50-00: null.
As this is an UTE device you have to pair it through the “SCAN” or device discovery. Otherwise it would not react on messages from openHAB.
I will investigate this.

Daniel

[fruggy83 (Daniel Weber)]

HI Berti @Bize ,

I found the bug, message validation does not handle the teach in message correctly. Sorry. I will release a new version tomorrow.

Daniel

[Bize]

Hi Daniel @fruggy83,

ok understood. Sounds good. As soon as you have released the new version, I will test it.

BR
Berti

[DrRSatzteil (Thomas Lauterbach)]

Hi everyone,

first of all: I’m taking my very first steps with the binding, the whole EnOcean ecosystem in general and the used hardware. I’m struggling to setup an EnOcean gateway with an ESP8266 and the EnOcean Pi module.

I guess this is most likely not an issue with the binding but probably my own inability somewhere along the way… Please let me know if this question is therefore inappropriate in this thread, I will create a new one then.

Since I might be completely on the wrong path so some help would be really appreciated.

This is my current setup:
Board: https://www.az-delivery.de/products/nodemcu with EnOcean Pi from element14
I use the library from: GitHub - Techserv-krY/EnOcean_ESP8266_Gateway: Enocean Gateway 1to1 Telegram to TCP over WiFi, inkl OTA and Wifi Manager / Node-Red

I use the following path: rfc2217://10.9.0.195:9999

The problem:
When I try to connect to the bridge I see that messages to retrieve base id and version are sent out in the TRACE log:

2021-03-09 19:46:02.987 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2021-03-09 19:46:02.989 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2021-03-09 19:46:02.993 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2021-03-09 19:46:02.995 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2021-03-09 19:46:02.998 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2021-03-09 19:46:02.999 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2021-03-09 19:46:03.001 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2021-03-09 19:46:03.250 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2021-03-09 19:46:03.252 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2021-03-09 19:47:03.002 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2021-03-09 19:47:03.004 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2021-03-09 19:47:03.007 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing serial output stream
2021-03-09 19:47:03.009 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closeing serial input stream
2021-03-09 19:47:03.011 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing serial port

When connected to the diag port on the esp8266 I see:

Client connected
Net > Ser:: FF FB 00 
Net > Ser:: FF FD 00 FF FB 03 FF FD 03 FF FB 2C 55 00 01 00 05 70 08 38 
Net > Ser:: 55 00 01 00 05 70 03 09

And then nothing until the binding runs into a timeout apparently.

This is the output of tcpdump -i bond0 -nn -s0 -v host 10.9.0.195 (10.9.0.195 is my gateway and 10.9.0.101 is my openhab instance):

tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:24:58.327600 IP (tos 0x0, ttl 64, id 3661, offset 0, flags [DF], proto TCP (6), length 60)
    10.9.0.101.39508 > 10.9.0.195.9999: Flags [S], cksum 0x1568 (incorrect -> 0x43e8), seq 2315558440, win 64240, options [mss 1460,sackOK,TS val 3526047793 ecr 0,nop,wscale 7], length 0
22:24:58.434140 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.9.0.101 tell 10.9.0.195, length 46
22:24:58.434192 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.9.0.101 is-at e6:ef:7c:b2:63:9e, length 28
22:24:58.435897 IP (tos 0x0, ttl 255, id 2350, offset 0, flags [none], proto TCP (6), length 48)
    10.9.0.195.9999 > 10.9.0.101.39508: Flags [S.], cksum 0x6575 (correct), seq 6667, ack 2315558441, win 2144, options [mss 536,nop,nop,sackOK], length 0
22:24:58.435978 IP (tos 0x0, ttl 64, id 3662, offset 0, flags [DF], proto TCP (6), length 40)
    10.9.0.101.39508 > 10.9.0.195.9999: Flags [.], cksum 0x1554 (incorrect -> 0x9c0c), ack 1, win 64240, length 0
22:24:58.436294 IP (tos 0x0, ttl 64, id 3663, offset 0, flags [DF], proto TCP (6), length 43)
    10.9.0.101.39508 > 10.9.0.195.9999: Flags [P.], cksum 0x1557 (incorrect -> 0x9c05), seq 1:4, ack 1, win 64240, length 3
22:24:58.688913 IP (tos 0x0, ttl 255, id 2351, offset 0, flags [none], proto TCP (6), length 40)
    10.9.0.195.9999 > 10.9.0.101.39508: Flags [.], cksum 0x8e9d (correct), ack 4, win 2141, length 0
22:24:58.689001 IP (tos 0x0, ttl 64, id 3664, offset 0, flags [DF], proto TCP (6), length 60)
    10.9.0.101.39508 > 10.9.0.195.9999: Flags [P.], cksum 0x1568 (incorrect -> 0x3d1a), seq 4:24, ack 1, win 64240, length 20
22:24:58.939192 IP (tos 0x0, ttl 255, id 2352, offset 0, flags [none], proto TCP (6), length 40)
    10.9.0.195.9999 > 10.9.0.101.39508: Flags [.], cksum 0x8e9d (correct), ack 24, win 2121, length 0
22:24:58.939261 IP (tos 0x0, ttl 64, id 3665, offset 0, flags [DF], proto TCP (6), length 48)
    10.9.0.101.39508 > 10.9.0.195.9999: Flags [P.], cksum 0x155c (incorrect -> 0x3d6c), seq 24:32, ack 1, win 64240, length 8
22:24:59.188998 IP (tos 0x0, ttl 255, id 2353, offset 0, flags [none], proto TCP (6), length 40)
    10.9.0.195.9999 > 10.9.0.101.39508: Flags [.], cksum 0x8e9d (correct), ack 32, win 2113, length 0
22:25:58.442132 IP (tos 0x0, ttl 64, id 3666, offset 0, flags [DF], proto TCP (6), length 40)
    10.9.0.101.39508 > 10.9.0.195.9999: Flags [F.], cksum 0x1554 (incorrect -> 0x9bec), seq 32, ack 1, win 64240, length 0
22:25:58.503090 IP (tos 0x0, ttl 255, id 2354, offset 0, flags [none], proto TCP (6), length 40)
    10.9.0.195.9999 > 10.9.0.101.39508: Flags [R.], cksum 0x36d1 (correct), seq 1, ack 33, win 24584, length 0
22:26:03.541689 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.9.0.195 tell 10.9.0.101, length 28
22:26:03.622344 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.9.0.195 is-at 3c:61:05:d4:f6:2c, length 46

My guess is that the code I’m using is just not compatible/broken or whatever. The author advertised his code here a while ago but there was no discussion about it so I’m not sure if anyone ever tried it. Any other suggestions (software or hardware related) are also very welcome!

[DrRSatzteil (Thomas Lauterbach)]

Ok so the main issue was my incompetence… (as expected)

After wiring the TX - RX correctly I get a response from the gateway (requests and responses get a bit mixed up here):

2021-03-09 23:10:35.836 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2021-03-09 23:10:35.837 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 5 optional length 1 packet type 2
2021-03-09 23:10:36.031 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2021-03-09 23:10:36.032 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2021-03-09 23:10:36.073 [TRACE] [ernal.transceiver.EnOceanTransceiver] - ESP3Packet malformed: 0084800AAA55

I’m not quite sure why the binding thinks that the package is malformed. It thinks that the header is ok:
2021-03-09 23:43:00.616 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 5 optional length 1 packet type 2 but it states that the data is corrupted. However I compared the message to the ESP3 specs and it looks ok to me. I can see the following message being sent from my gateway to OpenHab:

Ser > Net:: 0x55 0x00 0x05 0x01 0x02 0xDB 0x00 0xFF 0xF8 0x84 0x80 0x0A 0xAA 

This seems to be a valid response to CO_RD_IDBASE:
0x55 -> Sync Byte
0x00 0x05 -> Data Length
0x01 -> Optional Length
0x02 -> Response OK
0xDB -> CRC8H -> Ok according to Sunshine's Homepage - Online CRC Calculator Javascript
0x00 -> RET OK
0xFF 0xF8 0x84 0x80 -> Base ID within specified range (between 0xFF800000 and 0xFFFFFF80)
0x0A -> Remaining Write Cycles for Base ID -> No idea what that is but there are not restrictions according to the specs
0xAA -> CRC8H -> Ok according to Sunshine's Homepage - Online CRC Calculator Javascript

I have no idea where the leading 00 and the trailing 55 comes from in the log output though:
2021-03-09 23:10:36.073 [TRACE] [ernal.transceiver.EnOceanTransceiver] - ESP3Packet malformed: 0084800AAA55

[mdillman (Markus Dillmann)]

I don’t believe this (rather unusual) setup will work. In my view the main problem is that the ESP-software “sends Enocean packages 1-1 to tcp/wifi” whereas the biding just expects a serial interface, esp RFC2217 is “Telnet Com Port Control Option”.
So IF the ESP-software IS RFC2217 compliant/compatible it should work, but looking at the github site, the software is intended to be used differently with the associated node-red package.

You could ask the author of the ESP-software about RFC2217 compatibility.

[DrRSatzteil (Thomas Lauterbach)]

Thank you Markus, I will investigate a bit in this direction. There seem to be RFC2217 implementations around for ESP8266 so I might be able to combine this.

What’s strange however is that the response to the VERSION Request seems to be handled correctly by the binding according to the logs

[mdillman (Markus Dillmann)]

If you take a look into RFC2271 you’ll find some elements, which are needed to make good ole serial communications work (setting baud-rate, flow-control …). So it will send/receive some additional characters, which if sent 1-1 to the Enocean gateway, will confuse it and mangle the communication.

That is the pity with standards: if you only use it on one end, it will only “work” by accident.

[DrRSatzteil (Thomas Lauterbach)]

That’s true, it might just be coincidence then…

I will have a closer look at the standard and the binding code. Do you happen to know where the RFC2271 specific message handling is implemented? So far most of the code I was going through was all about the ESP protocols. I will find it eventually, was just wondering if you could give me a hint

[mdillman (Markus Dillmann)]

That stuff is not binding specific but is provided by OH on the framework-level. If you look in openhab-core you’ll find eg. org.openhab.core.io.transport.serial.rxtx.rfc2217.
That “addon” in core uses gnu.io.rfc2217

HTH
-Markus

[DrRSatzteil (Thomas Lauterbach)]

Apparently it is a lot of work to make my gateway understand RFC2217…

However I figured out a simpler way to do this by using socat and found a great way to set this up here in the community:

Can't use forwarded (socat) serial port in lgTVSerial Binding - IOException

Hi, I have openHAB 2.5.1 running in a docker container on my Synology NAS. I have my LG TV connected via the serial port to a raspberry pi in my network. I published the serial port from the raspberry pi using ser2net with the following config 3002:raw:0:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT # alternatively I used 600 as timeout value - no difference I build a custom docker image based on the openHAB 2.5.1 image in which I install socat and put the following script in /etc/cont-init.d/: …

Maybe this can help others who try to set this up in a similar way.

[DrRSatzteil (Thomas Lauterbach)]

Many thanks for this great binding!

I finally received my window sensor today and was able to add it fully functional to OpenHab much quicker than expected.

I use a Siegenia Senso Secure device. Even though it is super expensive I liked its features and I’m not planning to put them on every window (and I saved quite a bit of money by building my own gateway…). For configuration I setup a generic item that just transforms the whole message to a string item via the genericString channel:

(function(inputData) {

    var parts = inputData.split('|'),
        hexToBytes = function(hex) {
        for (var bytes = [], c = 0; c < hex.length; c += 2)
        bytes.push(parseInt(hex.substr(c, 2), 16));
        return bytes;
    };

    if(!parts || parts.length != 2)
        return null;

    var b = hexToBytes(parts[1]);
    switch(parts[0]){
        case "genericString":
            return "StringType" + "|" + b;
            break;

        case "genericRollershutter":
            break;

        case "genericDimmer":
            break;

        case "genericNumber":            
            break;

        case "genericColor":
            break;

        case "genericTeachInCMD":
            break;
    }

    return (inputData);
})(input)

I then implemented the message handling in a rule:

var messageBytes = newState.toString().split(",");

for (var i = 0; i < messageBytes.length; i++) {
  var messageType;
  switch (i) {
    case 0:
      // Message Type: 1 = Window Status, 2 = Alarm
      messageType = messageBytes[i];
      break;
    case 1:
      // Window Status or Burglary Alarm
      if(messageType == 1) {
        // Cut off first byte since it only indicates keepalive messages
        var windowState = messageBytes[i] & 127;
        if (windowState == 0) {
          // State: None
          break;
        }
        if (windowState < 4) {
          // Window is closed
          events.sendCommand('door_terrace_opening', "Geschlossen");
        } else if (windowState < 7) {
          events.sendCommand('door_terrace_opening', "Geöffnet");
        } else {
          events.sendCommand('door_terrace_opening', "Gekippt");
        }
        if (windowState == 1 || windowState == 4 || windowState == 7) {
          events.sendCommand('door_terrace_handle', "Geschlossen");
        } else if (windowState == 2 || windowState == 5 || windowState == 8) {
          events.sendCommand('door_terrace_handle', "Geöffnet");
        } else if (windowState == 3 || windowState == 6 || windowState == 9) {
          events.sendCommand('door_terrace_handle', "Gekippt");
        }
      } else {
        messageBytes[i] == 1 ? events.sendCommand('door_terrace_alarm', "ON") : events.sendCommand('door_terrace_alarm', "OFF");
      }
      break;
    // Bytes 2 - 5 are not interesting for us right now
    case 6:
      // Alarm messages are only 2 byte long so can be ignored here
      // First bit is the status
      if ((messageBytes[i] & 128) == 128) {
        events.sendCommand('door_terrace_battery_alarm', "ON");
      } else {
        events.sendCommand('door_terrace_battery_alarm', "OFF");
      }
      // Bits 2 - 8 are percentage values
      var batteryPercent = messageBytes[i] & 127;
        events.sendCommand('door_terrace_battery', batteryPercent);
      break;  
  }
}

I don’t acutally know if the alarm is working properly, I hit the window a couple of times but that was apparently not enough. I guess I’ll find out when the kids are playing soccer in the garden

[DrRSatzteil (Thomas Lauterbach)]

If this is of interest for anyone: the alarm does work (just had to hit the door a bit harder). However there does not seem to be a reset message after the end of the alarm as I expected. However I think it is actually better to reset the alarm manually should it ever go off so it does not go unnoticed.

One question: The binding seems to have problems to reconnect to a serial port of it disappears and is readded. I always have to restart OH for the bridge to come back up. Is this a known issue or does anyone know of a workaround?