[enocean] Support EEP-Profile D2-06-01 (Multisensor Window Handle / Soda window handle)

[blumentarzan]

It would be great to support the Soda window handle in openHAB by default. Thanks! Adrian

[DrRSatzteil]

Maybe I can have a go at this. Just finished D2_06_50 so this should be similar

[blumentarzan]

This would be great! Still have no solution for that... If I could help with testing just tell me.

[DrRSatzteil]

Good if you're still interested. Since I do not own one of their devices you would need to do the testing. The specifications for D2-02-01 are rather special since it theoretically supports a large number of different sensors (may differ from device to device) so depending on your devices abilities we might not be able to test all features of this EEP. I'll look some more info that in the next couple of days and will let you know when you can help me out with something.

[DrRSatzteil]

Hi @blumentarzan

I finished a very first version of this EEP that you might have a look at.

Please do not expect anything to work since I cannot test this myself. Hence it would be great if you could try to discover a device, attach the thing channels to items and play around a bit with it. Please watch the logs and paste any errors here. It might also help to adjust the log level (ssh to your OH on port 8101 e.g. "ssh openhab@localhost -p 8101" with password habopen and type: log:set debug org.openhab.binding.enocean)

A couple of notes:

• This implementation is currently read-only! That means that you won't be able to adjust any settings of your handle but only read sensor data from it.
• According to the specifications these devices potentially support a large amount of sensors (multiple buttons, motion sensor, humidity, temperature, etc.) however these may not all be present in every device. However you will see all channels not matter if the corresponding feature is supoorted by your device or not. If a channel is not supported it should never return any values. Right now I don't think this binding is designed to dynamically remove non-existent channels but this would be something for a later stage anyway.

For installation you should follow the following steps:

1. Remove the binding via UI (Note that all your devices will be temporarily offline if you use your production instance so make sure that this does not cause any trouble)
2. Wait until your enOcean bridge and devices complain about a missing handler (watch things in UI)
3. Move this file to your addons folder:
   https://drive.google.com/file/d/1LosRGjvgjCgA83lLueWGRqN35McxdBVF/view?usp=sharing
4. Wait a couple of seconds
5. Move this file to your addons folder
   https://drive.google.com/file/d/1vveOtN7u2yq7gLMSu9XY4Yvone2osSfW/view?usp=sharing
6. Wait until your things come back online and start by discovering a device (You need to delete a thing first to be able to rediscover it)

To revert back to stable version:

1. Remove the two added jar files from the addon folder
2. Wait until things complain abaout missing handler
3. Install official binding via UI
4. Rediscover the thing you deleted for 6. above. All your item links should be back as they were before.

[blumentarzan]

Hey @DrRSatzteil
Wow this is great news. Thanks!!!
I will test in the next days and get back to you.

[blumentarzan]

Hi @DrRSatzteil

Finnaly i had time to have test it. Sorry had some holidays.

After your steps i did the following:

• Scanned for new devices
• Put handle in learning mode
• Handle got discovered
• Added all the items

I can see the humidity of the window handle sensor. The rest does not seem to work. In the log file I do see some errors.

Here is the log file:
openhab.log

I once did some research for "D2-06-01" and saw that FHEM is supporting that profile. Maybe you can use that code (search for "D2-06-01"):
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/10_EnOcean.pm

How can I further help you to get that working. Maybe a remote session would help?`

Best regards
blumentarzan

[DrRSatzteil]

Hi @blumentarzan

Never mind I'm on vacation as well right now. Anyway we're not in a rush I think.

Great news that the discovery is working!

I know this FHEM implementation but the official specifications are usually easier to read than Perl code 😉 However manufacturer ID list in the code is quite handy.

You log file seems to be very helpful, it shows some errors in my code (haven't looked through all of it as I only have my tiny phone screen). Moreover I see some payloads I can use to do some testing on my own. I will come back to you once I find the time to fix these issues you discovered.

[blumentarzan]

Hi @DrRSatzteil

Perfect, that you can continue with my feedback. Enjoy your holidays!

[DrRSatzteil]

I'm back from my holidays and had a quick look. There is only one error in your logs that I fixed now. You may test again any time you want! The download link for 5. above will give you the updated file.

[blumentarzan]

Hi @DrRSatzteil

Great thanks!!
We are now a huge step further! It mostly works!!

Results of my testing:

No errors in the log anymore ;)

The following values have errors:

• Inndor Temperatur has a value of -58.7 °C, should be around 23 °C
• Battery Level has no value
• I can not link "Window Breach Event" and "Vacation Mode Toggle Event". They do no have a profile. See screenshot.

The rest seams to work. All values are updated as expected. Note that my handle does not support all values. See screenshot in DolphinView.

Here is the log of my testing. So you should be able to get the values:
openhab.log

DolphinView (green working, red not working corecctly, no marking not supported):

openHAB (green working, red not working corecctly, no marking not supported):

"Window Breach Event" and "Vacation Mode Toggle Event" link errors

Thanks!!
Blumentarzan

[DrRSatzteil]

Hai @blumentarzan ,

Great, this looks good. I will look into the Temperature and battery level channels, they still seem to be broken.

The vacation mode and burglary alarm behave as expected: note that these are trigger channels, they can be used to trigger a rule for example. If you want to link them to an item you should use a DateTime item and set the profile to 'Timestamp'. The problem with these is that the device does not send a state (like e.g. vacation mode is ON) but only an event: vacation mode was switched ON at the device (no event will be sent if it was changed via a config message). So in subsequent messages the device does not send the current state of the vacation mode but only the information that it's state did not change. On thing level I can only use this to create a trigger channel. You could of course have a switch item and change its state with a rule.

One question regarding the handle state: can you turn the handle left and right? Because thats what the device can send according to the specification. I would have expected something like open, close, tilted but here it is: up, right, down, left

[DrRSatzteil]

Hi @blumentarzan

I just updated the jar file once again. The two remaining issues should be fixed now. Please have a go and let me know if everything works smoothly now.

If everything works as expected we would need to update the README before we can issue a pull request.

The additional message types that could be sent by the handles however would be a completely different thing: Since you can only trigger the sending of these by sending a message to the device (within 500ms after a received message) this would require some more logic that is not yet implemented as far as I saw in the source code... If this would be implemented you could for example actually get the vacation mode state, however I would suggest to leave this task for a later point in time...

@fruggy83 This EEP contains a lot of channels that may be not supported by the device that implements it. The device then sends a "not supported" message. Does this binding allow me to dynamically remove channels from the thing depending on these messages? Right now the "not supported" channels will simply never show any value. Users might not know that their devices do not support certain channels and might think this is a binding issue which does not seem ideal.

[blumentarzan]

Hi @DrRSatzteil

Great thanks!!

The temperature is now correct. But the battery still does not show a value. In DolphinView i do see that value of currently 100%.

Here is the current log if that helps:
openhab.log

Regarding the additonal message types this is completly ok for me. These are not that important.

[DrRSatzteil]

The temperature is now correct. But the battery still does not show a value. In DolphinView i do see that value of currently 100%.

Hmmm, then I messed something up after I successfully tested the code... I will have another look, I already had this working

[fruggy83]

Hi @DrRSatzteil

currently the binding already creates the channels for a thing dynamically depending on the EEP. However this is done during thing initialization. After the init phase the binding does not change the channels anymore. It is possible to do change the channels afterwards but this would need further changes in the binding.
In this case I would suggest to declare these channels as advanced channels.

Best regards

[DrRSatzteil]

In this case I would suggest to declare these channels as advanced channels.

The problem is that this would only leave the battery level as a "non advanced channel". Moreover I'm not sure if this would really help to clarify what's going on. Maybe a note in the README would also do the trick since there is already some device specific information present.

@blumentarzan I found the problem in the latest binding version. You may have another go any time you want.

[fruggy83]

Hi @DrRSatzteil

sorry I have not read the EEP documentation before my answer. As most sensor values are optional this indeed would not look good in the gui. Another way to clarify this situation to the user would be to let him configure the thing and its channels. Define the optional sensor channels as "extensible" channels in the thing description (just like in the ClassicDevice) and add these channels as non "autoCreate" channels to the EEPType. In this case the user has to manually add the available channels to the thing. This would mimic the order process of a window handle where you could also add the sensors to your handle as you wish.
However a note in the README would be nice too 😄

[blumentarzan]

Good morning @DrRSatzteil

The battery level works!! Therefore I can give a go for the pull request ;)

Have a good weekend

[DrRSatzteil]

Hi @fruggy83

I will have a look at the non auto created channels, this sounds like a valid option. Thank you!

In case you had a look at the specifications: you maybe noticed that the sending of additional message types can be triggered if the gateway replies to a message within a specified time. I assume there is no such functionality available yet in the binding, correct?

[DrRSatzteil]

Good morning @DrRSatzteil

The battery level works!! Therefore I can give a go for the pull request ;)

Have a good weekend

Great! When I find the time I will update the Readme and check if it makes sense to make further adjustments to the channels (as suggested by fruggy83). Will give you a heads up when I'm done.

[DrRSatzteil]

@fruggy83 I just had a look how these extensible channels work. In general I like the idea, however this would require me to create a whole new thing type. Right now I use the same thing type as for the D2_06_50 EEP but these extensible channels don't make any sense for these devices...

To be honest I'm not so sure in general where to put the D2_06_01 EEP: Since the Soda devices are actually window handles it probably would make even more sense to add them to the mechanicalHandle thing type. This would also not solve the problem withe the extensible channels (since the other handles don't support these) but it would be the much more intuitive choice in the UI.

[DrRSatzteil]

I decided to move the handle to the mechanicalHandle thing type since this just makes a lot more sense from a users perspective to select the mechanicalHandle thing type in the UI. Apart from that I also finally managed to update the README.

@blumentarzan These changes should not really break anything but of course we would need a (hopefully last?) test before I create the PR. Could you please try this once again and check if everything still works as expected?

If you are still using the last binding version that I uploaded please bear in mind that the thing type changed in this version. Therefore this new version is not backwards compatible and you would need to rediscover your handle for testing.

[blumentarzan]

Hi @DrRSatzteil

Thanks!!

I tested everything once more. In this version the buttons do not work. They always show up NULL in the UI. The rest is working fine.

Here is the error. The last entrys are button pushes:
openhab.log

And I would suggest one small change:
Rename the channel "push button" to "push button 1". With that the order is the rigth way in the ui.

Best regards

[DrRSatzteil]

Hi @blumentarzan

Hm, you mean the two pushbuttons? That's strange since all other channels are working and I did no changes to the actual EEP handling.

It seems that only the last couple of lines are relevant from your log file. The messages I see there however do not show a button push.

In these lines you should see something different that the two zeroes (marked with stars) at this location if a message contains a pushbutton event:
ESP Packet payload D2000F41**00**F29B68FFFFA00410CA4B00 for 0410CA4B received

Can you somehow confirm that you received a message with a pushbutton event?

Regarding your suggestion of renaming "push button": While I see the benefit of this I wouldn't want to change this right now since this channel was already defined and is therefore already in use by a lot of people. Moreover your device is the first and currently only suipported device that has a second push button. It would be a bit weird to have a push button 1 for devices that only actually support one.

[blumentarzan]

Hi @DrRSatzteil

Sorry!! Nearly missed to write back... I rechecked everything. Now it works. Maybe the restart solved the problem.

Thefore I can give a go for the release. Thanks!!!

[DrRSatzteil]

This issue should be closed. Changes have already been merged.

[lolodomo]

Done