New openHab2 EnOcean binding

First of lot, let me say kudos for this binding! I was still stuck to FHEM for the enocean part of my setup, hopefully I can make the switch :slight_smile:

I have a bunch of PEHA devices and have some troubles setting them up. Iā€™ve manage to succesfully setup my roller-shutters, including feedback from the shutter about their position.

I do have some problems with the feedback from my PEHA D 452 FU-EBI OT switches. Via manual addition of the thing, I can switch the light by generating a A5-38 Central Command Thing using the proper IDs. Iā€™ve tried the A5-11-03, PTM200 and A5-38-08 sub command 0x02 EEP for the receiving EEP, but unfortunatly no proper feedback is set on OH when I switch the light via another (physical) rocker.

This is what I see in the logs:
2018-10-22 15:44:23.357 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - RADIO_ERP1 with RORG _4BS for FFD3E302 payload A50000BF48FFD3E3020003FFFFFFFF2E00
2018-10-22 15:44:23.360 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet payload A50000BF48FFD3E30200 for FFD3E302 received

Does anybody have a clue? Many thanks in advance!

Hello Daniel (@fruggy83 ) and thank you for your respond.
After days of trouble i had resolved the problem tomorrow thanks to a power outageā€¦
The Pi is under UPS, the NodeOn no. After the outage iā€™ve started to see the RSSI of the relay. I think that these devices sometimes they could need (!!!) a power cycle.

I confirm that iā€™ve not updated the binding nor added other sensors or devices. The relay is about 3 meters away from the usb bridge so i donā€™t think it was a distance problem. As i see a brutal, but effective, reboot of the relay had resolved the issue. Thank you a lot for the binding and your work, really.

(and the discovery problem could be related also to the erratic functioning of the relay)

Thanks a lot again

@fruggy83 mmmh no the problem is still here: iā€™ve tried to reboot the pi and then the same relay send null RSSI signal information. Iā€™ve just remebered that the last week iā€™ve accidentally unplugged the ups causing the reboot of the pi with openhabian (when the relay was still on)
I dont understand why rebooting the pi cause this issue. Where i had to look on the logs, by your experience?

Hello Vincent (@vince2k),

I looked into the docs of your PEHA switch. I am sorry to say that this switch just answers with EEPs which are currently not supported yet. However I have already implemented parts of the D2-01 EEP. The needed D2-01-08 EEP should be really easy to implement. I should find some time tomorrow to do this. However as you maybe already read, I am trying to implement an official binding and do not want to further work on this older version of the binding. So if you want to be ahead of nearly everybody else, you should use the newer version of the binding from my other repo.

Best regards
Daniel

@fruggy83: thanks for your reply. I also did take a look at the docs of my PEHA device, it seems it is reporting using EEP A5-11-04 (Extended Lighting Status). Iā€™m still a enocean noob and still have no complete picture how a datagram looks like, but from the small bit of information I think the interesting part of the payload are:
A50000BF48 for an OFF:
A5 4BS
00 (p1: 0 dimvalue)
00 (P2: 0 )
BF (P3: 191 hours (see below))
4(0100 -> normal mode,hours available, no error)
8(1001 ->Data telegram, 8bit dimmer + hours available, 0-> lighting off)

A5FF00BF49 for an ON.
A5 4BS
FF (p1: 255 dimvalue)
00 (P2: 0 )
BF (P3: 191 hours (see below))
4(0100 -> normal mode,mode 0: hours available, no error)
9(1001 ->Data telegram, 8bit dimmer + hours available, 1-> lighting on)

Seems to be consistent.
@fruggy83: Do you need some help in development? Iā€™m new to enocean and OH2 development, but Iā€™m more than happy to help.

Hello Frederico (@execcr),

I am really sorry but currently I have no idee what happening there. This is really strange. If you have not done it already, you could activate the debug log of the binding in the karaf console by using the following command:

log:set DEBUG org.openhab.binding.openocean

Afterwards you will see every received message.If you receive a message without an item update, you could post this message (and the ones before and after) here, so I can analyse it further. I keep my fingers crossed.

Best regards
Daniel

@vince2k:
thanks a lot for your analysis. This looks really good :+1: If it is ok for you (and if you do not need the working hours of your lights) I would first start to implement the D2-01-08 EEP as I already implemented D2-01-09 and some other messages of this EEP family. Furthermore you are able to auto discover your switches with this EEP. However pull requests are always welcome :wink:

Thank you Daniel for the tip.
Here the result:
In my panel when i press ON and OFF a channel of the problematic relay:
2018-10-22 22:43:17.027 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:43:17.032 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010101FF99F60500010508694BFF000E

2018-10-22 22:43:17.664 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461E40508694B00 for 0508694B received

2018-10-22 22:43:22.352 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:43:22.361 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010100FF99F60500010508694BFF009A

2018-10-22 22:43:23.003 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461800508694B00 for 0508694B received

Here instead another relay (one that send RSSI information):

2018-10-22 22:45:01.846 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:01.863 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010100FF99F6060001FFFFFFFFFF0070

2018-10-22 22:45:02.838 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D2046180050E7A2000 for 050E7A20 received

2018-10-22 22:45:02.854 [vent.ItemStateChangedEvent] - openocean_measurementSwitch_8eabb372_050E7A20_receivingState changed from Rssi 86, repeated 0 to Rssi 88, repeated 0

2018-10-22 22:45:15.023 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:15.026 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 550009070156D2010101FF99F6060001FFFFFFFFFF00E4

2018-10-22 22:45:16.246 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461E4050E7A2000 for 050E7A20 received

2018-10-22 22:45:16.268 [vent.ItemStateChangedEvent] - openocean_measurementSwitch_8eabb372_050E7A20_receivingState changed from Rssi 88, repeated 0 to Rssi 86, repeated 0

And here some messages i receive without item update:

2018-10-22 22:45:27.612 [DEBUG][an.handler.OpenOceanBaseThingHandler] - polling channels

2018-10-22 22:45:27.618 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.617 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels

2018-10-22 22:45:27.624 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.621 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels

2018-10-22 22:45:27.626 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20300FF99F6010001050DA278FF00BD

2018-10-22 22:45:27.632 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.651 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - polling channels

2018-10-22 22:45:27.654 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.651 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.654 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.658 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - new request arrived

2018-10-22 22:45:27.799 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20301FF99F6020001FFFFFFFFFF0052

2018-10-22 22:45:28.292 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D2046080050DA27800 for 050DA278 received

2018-10-22 22:45:28.303 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20301FF99F60500010508694BFF005B

2018-10-22 22:45:28.477 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20301FF99F6060001FFFFFFFFFF00B1

2018-10-22 22:45:28.971 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D204618005069E0A00 for 05069E0A received

2018-10-22 22:45:28.986 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20300FF99F60500010508694BFF00CF

2018-10-22 22:45:29.179 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20300FF99F6060001FFFFFFFFFF0025

2018-10-22 22:45:29.364 [DEBUG] [nal.transceiver.OpenOceanTransceiver] - 55000807013DD20300FF99F6020001FFFFFFFFFF00C6

2018-10-22 22:45:29.838 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461E4050E7A2000 for 050E7A20 received

2018-10-22 22:45:30.644 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D2046080050E7A2000 for 050E7A20 received

2018-10-22 22:45:31.283 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20460E405069E0A00 for 05069E0A received

And here when i press the Wall Switch of the problematic Relay:
(but status will not be updated in the panel)

2018-10-22 22:47:46.952 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet D20461E40508694B00 for 0508694B received

2018-10-22 22:47:47.389 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet F6500508694B30 for 0508694B received

2018-10-22 22:47:47.402 [vent.ChannelTriggeredEvent] - openocean:rockerSwitch:8eabb372:0508694B:rockerswitchB triggered DIR2_PRESSED

2018-10-22 22:47:47.820 [DEBUG] [an.handler.OpenOceanBaseThingHandler] - ESP Packet F6000508694B20 for 0508694B received

2018-10-22 22:47:47.827 [vent.ChannelTriggeredEvent] - openocean:rockerSwitch:8eabb372:0508694B:rockerswitchB triggered DIR2_RELEASED

Hi Frederico (@execcr),

from your last messages I can see that your switch also sends rocker switch messages (ESP Packet F6). Furthermore you have defined a rocker switch thing which reacts on these messages

openocean:rockerSwitch:8eabb372:0508694B:rockerswitchB triggered DIR2_PRESSED

So I am wondering if you really have defined a measurement switch thing with Id 0508694B or just a rocker switch thing? If your have defined a rocker and a switch, you should remove the rocker as I am not sure what happens if two things of different types have the same Id. Maybe just one of them receives the message in this case.

Best regards
Daniel

Hi Daniel (@fruggy83)
Just to be sure to use the same vocabulary:
Wall Switch: the switch wired directly to the actuator
Rocker Switch: a wireless wall switch based on Enocean protocol.

The latter i have 2 connected to the switch (one from one year or so, the other from 1 month, but the rssi worked after i connect the last to the relay)
The oldest one in made by NodeOn (Pink)
The newer is from Vimar and is a fancy and pricey version of the NodeOn but is the same ā€œfamilyā€ of my wall switch, which is nice.
Attached you will find the PaperUi problematic relay (the 0508694B)

The 2 rocker switch

And here the pink switch that is defined in openhab too from a year ago:

Do you think that the wireless rocket switchers are causing troubles?

@fruggy83: Iā€™ve just implemented the switch state using A5-11-04, so youā€™ve got mail/a pull request :slight_smile:

Hey Daniel (@fruggy83),

quiet some action here in this thread :slight_smile:

Iā€™m totally aware of this. I think if I stood with openocean, you would have to merge all my PRs to the new repo, and I wouldnā€™t get all the new features :wink: Iā€™m not dependent on a working binding, so consider me as a beta tester who can help fixing if something gets broken.

Let me show you the total usage history of one of my devices:


The value should never decrease, so the history is confusing and I think this is a problem. The question is if this is a problem of the binding, or a problem the user should care on his own. I tend to prevent this in the binding, since we know that these channels are channels where the value can only increase. A proposal how it could be done is on the way, I have to test it over the night first :slight_smile:

The implementation of FWZ12 was very straight forward, since it uses the A5-12-01 EEP for Energy measurement:

Thing automatedMeterSensor 12345678 "Strom Phase I" @ "Flur" [ enoceanId="12345678", receivingEEPId="A5_12_01" ]

automatedMeterSensor was not published to use, I did so and added that to the PR. From the documentation, it seems that the FUD61NPN uses an EEP similar to A5-38-08. Do you know if I can use your implementation ā€œA5_38_08_Dimmingā€ for this? And, do you know which EEP I have to send to turn on the light alarm clock?

Cheers,
Dominik

Hello Frederico (@execcr),

thanks a lot for your pictures. If you look at the channels of your relay ā€œrele zona notte 2ā€ and your rocker switch ā€œpulsante rosaā€, you will see that both have the same ThingId (4th part of the channel id) 0508694B. However it is stated in the enocean docs that this Id is unique among all enocean devices. As my binding relays so deeply on this fact, you will get a problem as the binding cannot distinguish between your relay and rocker switch.
Each enocean message contains a SenderId, this is the EnOceanId of the sending device, which must be used as the ThingId of your openhab thing representing this device. The binding looks at this Id and searches an openhab thing with the same ThingId. The first found one will get the message and handles it. So it depends on the order of your thing definition, which message can be interpreted and which not.

The question is, are these Ids correct and how did you get them?

Best regards
Daniel

Hi Vincent (@vince2k),

thanks a lot for your work, I will merge it after some slightly changes. However could you do me a favor and sign your commit. Without signing it, I cannot merge it into the official version of this binding (and mention you in the credits :wink:)

Best regards
Daniel

Hi Dominik (@dominikkv),

Iā€™m totally aware of this.

Thanks a lot for your understanding and your testing efforts. An automatic merge of your PRs is a lot of safer than my manual one (as you saw :crazy_face:). I hope to find some time to merge your PR in the next days and rearange the repo (adding a new dev branch)

The question is if this is a problem of the binding, or a problem the user should care on his own.

First of all I am very interessted in your proposal for this problem. But what do you think about to deactivate the polling of the energy data in your D2-01 NodOn thing? In this case you should only get the precise A2-12 values.

The implementation of FWZ12 was very straight forward

Glad to hear this. Maybe this could be an interessting holiday project :thinking:

Do you know if I can use your implementation ā€œA5_38_08_Dimmingā€ for this?

I am really sure that you can use this profile. If you look at this doc, you see that my FUD14 and your FUD61NPN use exactly the same EEP. I wish all manufacturers would provide such a good documentation.

And, do you know which EEP I have to send to turn on the light alarm clock?

I am not quite sure. Eltako sells a FSU14 which uses the A5-13-04 EEP. Maybe this EEP has to be teached into your FUD61. However if you look at the doc, you will see that the FSU14 also sends simple rocker switch messages (PTM200). Maybe you should try a genericThing with the switch channel in combination with a timer rule.

Best regards
Daniel

Thank you Daniel for your patience and the explanation!
I think iā€™ve understand what is happen:
A year ago iā€™ve provisioned all the modules in a test installation with the same usb c300 bridge (And ā€œrele zona notte 2ā€ and ā€œpulsante rosaā€ have been connected each other before the openhab setup). Then iā€™ve done a full new setup, provisioning again the relay in a new openhab installation (but i didnā€™t reset them).
Maybe some relay had double adresses. Itā€™s possible that they responded to the ON-OFF commands but not to send rssi information on newer ThingIDs? By the way, i didnā€™t experience any problem until the power goes out for the first time after months iā€™ve done the first setup.

To be sure, iā€™ve now reset every relay and provisioned them again in openhab: itā€™s all working ok now, i get all the RSSI. signals.
I think one relay is a bit on the edge becouse i get rssi levels of 91-92, so iā€™ve activated level 1 repeater for 2 relays near it and level 2 for the bridge (made it by multiple trials, without the level 2 for the bridge some commands didnā€™t reach the farther relay i donā€™t know why).

Thank you again, really!

Hi Daniel,

i re-installed your binding, link from your first post, but i still had to install the openhab-transport-serial.
Do i need to get the binding from a different link?

regards
Matt

Hi Matt (@Matt77),

I am working on an official version of his binding. This version has some improvements over the openocean binding, which I do not migrate back.You find the newer version of this binding in my openhab/addons2 fork or wait until you can install it directly from within openhab.

Best regards
Daniel

Hi Frederico (@execcr),

glad to hear that it works now :+1:.

i get rssi levels of 91-92

That is really bad. I also have to use a repeater to get a stable connection to all of my switches. However I observed that to much repeaters made more problems than they solved. So I am currently using just one repeater.

Best regards
Daniel

hi @fruggy83

Iā€™d like to control a Sonos speaker in the bathroom with the Nod On CRC-2-6-01 Soft Remote (enocean items trigger sonos items via rules). Do you think this remote will work out of the box with your binding?

Thank you very much in advance.