Recipient sometimes does not confirm - only with rules

Add-ons Bindings
1

The following problem. I have a new Openhab basic installation 3.01 and 3.1 M3 tested. Operating system is openhabian latest version and I run it with a z-wave (ZMEEUZB1) and enocean (USB300) stick.

UID: enocean:bridge:FTZ19097
label: Enocean USB300 Dongle (FTZ19097)
thingTypeUID: enocean:bridge
configuration:
rs485BaseId: “00000000”
path: /dev/ttyUSB0
rs485: false
enableSmack: true
espVersion: ESP3
sendTeachOuts: false

For testing I have installed a Switsch Nodeon 2-1-0 and a Z-WAVE PIR sensor. The whole thing works very well by hand control.

UID: enocean:measurementSwitch:FTZ19097:0589722A
label: Licht Flur Unten Gerät
thingTypeUID: enocean:measurementSwitch
configuration:
enoceanId: 0589722A
senderIdOffset: 1
pollingInterval: 300
suppressRepeating: false
sendingEEPId: D2_01_0F_NODON
broadcastMessages: false
receivingEEPId:
- D2_01_0F_NODON
bridgeUID: enocean:bridge:FTZ19097

I had first opened a thread here. Unfortunately, the problem is probably more on the Enocean side to look for.

But as soon as I use Rules it doesn’t work anymore. Here is what happens: (Or not)

10:40:18.819 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'PIRFlurUntenGeraet_MotionAlarm' changed from OFF to ON
10:40:18.825 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LichtFlurUntenGerat_Switch' received command ON
10:40:18.830 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LichtFlurUntenGerat_Switch' predicted to become ON
10:40:18.837 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUntenGerat_Switch' changed from OFF to ON
10:40:18.838 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
10:40:18.842 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E01FFA7838100010589722AFF00
10:40:18.868 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
10:40:19.191 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0001FFFFFFFF4400 received
10:40:19.194 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received
10:41:07.835 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'PIRFlurUntenGeraet_MotionAlarm' changed from ON to OFF
10:41:07.845 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LichtFlurUntenGerat_Switch' received command OFF
10:41:07.852 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LichtFlurUntenGerat_Switch' predicted to become OFF
10:41:07.857 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUntenGerat_Switch' changed from ON to OFF
10:41:07.862 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
10:41:07.866 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E00FFA7838100010589722AFF00
10:41:07.884 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
10:45:00.915 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - polling channels
10:45:00.920 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
10:45:00.927 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2031EFFA7838100010589722AFF00
10:45:00.948 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
10:45:01.079 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0001FFFFFFFF4400 received
10:45:01.085 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received
10:45:01.093 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUntenGerat_Switch' changed from OFF to ON

That is, the switch correctly receives the power on and confirms it. The switch off is sent but not received. After some time it polls the device and gets the answer that the device is still on. So it sets the status of the switch on the web page back to on.
As I said, this only happens with rules, not once when I switch manually (web page).
What have I already done? Of course I reseted the switch and reprogrammed it. Openhab changed to version 3.1 M3. Everything has brought no improvement. The same config with two other devices has the same error. Oh yes and with Homee it runs unfortunately without problems. But would like to use Openhab, because I like the logic much more than eg home assistant.

Can you help me?

Oh yes the distance between transmitter and receiver is about 2 m without concrete ceiling or other :wink:

But it also raises the question for me, why doesn’t he try again? I have so in mind that Enocean the
repeats the sending until a confirmation arrives? Is not that the case with a gateway?

2

First, forget the PIR and your rule to take out complexity.
Do a proper pairing of your Nodon (my guess is your problem is there) and try to control it afterwards via the channels linked to a switch item.
Also test the feedback way: control your Noddon via local switch and the state of your linked switches in OH needs to chnage.

Once you have that working, put the PIR and rules back into the picture.

3

Thank you for the answer. Both work. Both the control of the Nodon with a local switch, and the subsequent change on the website of Openhab. It works the other way around. So changing the switch on the Openhab website always switches the Nodeon. This always works 100%!
As soon as I bring the rule back into play, the behavior described above starts again.

4

It is still very confusing to me what you write and what works and what does not. Esp. as you write in the other thread, that you do NOT receive feedback/confirmation.
And how do you "execute a rule manually " ?

The rule engines are just talk to the OH event bus, so if things work in blockly (what what I understood in the other post), and don’t work in the other engine, the problem might be there but most likely is NOT on the Enocean-binding layer.

How is your switch-item defined and to what channel of the Nodon is it linked ?

5

What the events log shows is sending commands in very quick succession. Maybe before the previous one has settled down. You’re probably getting a response to command-one after command-two has been sent.

What might be helpful is showing the events.log sequence for a UI triggered on or off, that you say works. In particular, when does the next “polling channels” debug come along?

6

Okay, so let’s go in order. Unfortunately my english is not so good. So what works is the following:
Variant one. The simplest variant. The nodeon is switched manuel via the item on the Openhab website.

16:03:51.163 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E01FFB18B0100010589722AFF00
16:03:51.182 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
16:03:51.215 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFB18B01 payload D2011E01FFB18B0181000589722A4A00 received
16:03:51.776 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0000FFFFFFFF4900 received
16:03:51.781 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received
16:07:02.342 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - polling channels
16:07:02.346 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
16:07:02.350 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2031EFFB18B0100010589722AFF00
16:07:02.374 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
16:07:02.418 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFB18B01 payload D2031EFFB18B0181000589722A4900 received
16:07:02.502 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0000FFFFFFFF4900 received
16:07:02.508 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received

I can do that as often as I want. It always works.

Variant two. I switch the Nodeon manual with one local switch.

16:13:10.085 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 0589722A payload F6300589722A3100FFFFFFFF4A00 received
16:13:10.093 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 0589722A payload F6000589722A2100FFFFFFFF4900 received
16:13:10.375 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0100FFFFFFFF4C00 received
16:13:10.381 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A01 for 0589722A received
16:13:10.391 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUnten_Switch' changed from OFF to ON
16:17:02.393 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - polling channels
16:17:02.401 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
16:17:02.408 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2031EFFB18B0100010589722AFF00
16:17:02.435 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
16:17:02.453 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFB18B01 payload D2031EFFB18B0181000589722A4700 received
16:17:02.549 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0000FFFFFFFF4600 received
16:17:02.556 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received

The item in Openhab is correctly set to On. This also works 100% of the time.
With this, we can first state, manual no matter how, always works.

7

The fun begins as soon as a rule is installed.
I use a very simple rule for the following logfile. No Blocky.

triggers:
  - id: "1"
    configuration:
      itemName: PIRFlurUntenGeraet_MotionAlarm
      state: ON
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: LichtFlurUnten_Switch
      command: ON
    type: core.ItemCommandAction

Initial state as always, everything off.

16:27:37.598 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'PIRFlurUntenGeraet_MotionAlarm' changed from OFF to ON
16:27:37.614 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LichtFlurUnten_Switch' received command ON
16:27:37.620 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LichtFlurUnten_Switch' predicted to become ON
16:27:37.625 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
16:27:37.629 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E01FFB18B0100010589722AFF00
16:27:37.633 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUnten_Switch' changed from OFF to ON
16:27:37.656 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received

Here is what happens now. I see on the web page of Openhab, the item of the PIR go from OFF to ON. (As also in the logfile). After that the item of the nodeon on the webpage also goes to ON. But the Nodeon itself is not switched ON!

Now comes the polling cycle.

16:32:02.505 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - polling channels
16:32:02.510 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
16:32:02.514 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2031EFFB18B0100010589722AFF00
16:32:02.538 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
16:32:02.556 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFB18B01 payload D2031EFFB18B0181000589722A4900 received
16:32:02.666 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460800589722A0000FFFFFFFF4600 received
16:32:02.670 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460800589722A00 for 0589722A received
16:32:02.678 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUnten_Switch' changed from ON to OFF

This will correctly set the item from nodeon switch on the weppage of Openhab to OFF again.
There are no other entries between the log and the log of the polling cycle.
Does that help? What other information do you need?

Here is the definition of the item from the Nodeon:

LichtFlurUnten_Switch (Type=SwitchItem, State=ON, Label=Unten, Category=light, Tags=[Light, Point], Groups=[LichtFlurUnternGeraet])

And one more addendum. Referring to the other thread. At the beginning it looked like it would work with Blocky. But it didn’t. In the live test in the evening there were very quickly again these problems.

8

And this is what it looks like once it works. In about 1 out of 10 cases:

16:55:48.859 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'PIRFlurUntenGeraet_MotionAlarm' changed from OFF to ON
16:55:48.869 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LichtFlurUnten_Switch' received command ON
16:55:48.877 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LichtFlurUnten_Switch' predicted to become ON
16:55:48.882 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUnten_Switch' changed from OFF to ON
16:55:48.883 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
16:55:48.886 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E01FFB18B0100010589722AFF00
16:55:48.904 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
16:55:49.243 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0000FFFFFFFF4600 received
16:55:49.247 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received
9

Would you confirm which Item gets the command when you “switched manual via openHAB website”? It just happens that none are shown.

On the face of it, it looks like Insteon messes up sending an outbound command soon after in inbound.

10

Sorry, I had copied too little above.This is once again manually via the website.

16:59:12.122 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LichtFlurUnten_Switch' received command ON
16:59:12.128 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LichtFlurUnten_Switch' predicted to become ON
16:59:12.136 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LichtFlurUnten_Switch' changed from OFF to ON
16:59:12.137 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
16:59:12.142 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E01FFB18B0100010589722AFF00
16:59:12.169 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
16:59:12.188 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFB18B01 payload D2011E01FFB18B0181000589722A4A00 received
16:59:12.763 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0589722A payload D20460E40589722A0000FFFFFFFF4600 received
16:59:12.768 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E40589722A00 for 0589722A received
11

Okay, sometimes people get confused with similar Items linked to same channel.

To test for a timing issue, have the rule sleep for a second before sending command.

12

Sorry for the question. I am just getting to know Openhab. How do I do that?
ah

Thread::sleep(1000)

okay i test

13

Then it works.
Only 100ms is also enough. Or not :wink: It works with 100 often but not always.

14

After an evening test, I can say that a delay of 500ms is sufficient for stable switching. But what do I do with the result? Of course I can operate this for me, but is there not a problem somewhere? One would have to go to the reason. The question is from which side? Is it rather a topic in the Enocean layer or nevertheless a topic of the Rules?
I am not so clear where to prescribe the subject.

15

The hundreds of people using openHAB do not generally have to add delays into their rules.

Looks to me like enocean is messing up, not allowing a gap between radio packets or somesuch. Maybe your enocean gateway settings need a tweak.

16

Okay, I have written to the developer. Let’s see how it goes. Thank you and have a nice Sunday,