add support for EEP D2-01-0C for avidsen and nodon

[remisharrock]

I would like to have the EEP D2-01-0C running. It is used to control electrical heaters in France and measure their energy consumption.
Both Nodon and Avidsen have implemented this EEP profile.

Here is the nodon controller:
https://nodon.fr/nodon/module-chauffage-fil-pilote-enocean/

Here is the avidsen controller:
https://www.avidsen.com/cache/documents/product/fp_module-de-chauffage-fil-pilote-516207-avidsen-847.pdf

little test of the avidsen in this article: https://www.domotique-info.fr/2017/04/test-module-fil-pilote-enocean-by-avidsen/

Is it implemented ?
How can I help implementing it ?

Thank you for your help !

[remisharrock]

It looks like on this PDF, page 144 of 270 shows the eep sent by avidsen:
https://www.enocean-alliance.org/wp-content/uploads/2017/05/EnOcean_Equipment_Profiles_EEP_v2.6.7_public.pdf

also 139 of 270 explains the "cmd 0x8 actuator set pilot wire mode" that is of interest :
0x00 Off
0x01 comfort
0x02 eco
0x03 anti-freeze
0x04 comfort - 1
0x05 comfort - 2

and also the "cmd 0x9 - actuator pilot wire mode query" and "cmd 0xA - actuator pilot wire mode response" that can reply with the same numbering as with cmd 0x8 above.

so how can I implement all that :) ?

[remisharrock]

So I found this file

https://github.com/fruggy83/openocean/blob/master/src/main/java/org/openhab/binding/enocean/internal/eep/D2_01/D2_01_0C.java

but It looks like it is not implemented, even if I look in https://github.com/fruggy83/openocean/blob/master/src/main/java/org/openhab/binding/enocean/internal/eep/D2_01/D2_01.java

I can see

protected final byte CMD_ACTUATOR_SET_STATUS = 0x01;
protected final byte CMD_ACTUATOR_STATUS_QUERY = 0x03;
protected final byte CMD_ACTUATOR_STATUS_RESPONE = 0x04;
protected final byte CMD_ACTUATOR_MEASUREMENT_QUERY = 0x06;
protected final byte CMD_ACTUATOR_MEASUREMENT_RESPONE = 0x07;

but there is no command for 0x08 or 0x09 or 0x0A as explained above ?

[fruggy83]

Hi @remisharrock

I did not know what this "pilot wire mode" is for, so I did not implemented it yet. However with the help of your docs, this is clear now. Do you have a testing environment where you could test a new openocean version? It would be fine if we could test my implementation before I merge it to official.
I will implement it this weekend.

Best regards

[remisharrock]

@fruggy83 Yeaah ! I will install it tonight or tomorrow and will be able to test everything !
Thank you so much :)

[remisharrock]

thank you for your work. I tried to clone and compile with maven but could not find the parent org.openhab.addons.reactor.bundles version 2.5.1-SNAPSHOT

I get this error :

mvn compile
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for org.openhab.addons.bundles:org.openhab.binding.openocean:2.5.1-SNAPSHOT: Could not find artifact org.openhab.addons.bundles:org.openhab.addons.reactor.bundles:pom:2.5.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 6, column 11
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project org.openhab.addons.bundles:org.openhab.binding.openocean:2.5.1-SNAPSHOT (C:\Users\remis\Documents\openocean\pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for org.openhab.addons.bundles:org.openhab.binding.openocean:2.5.1-SNAPSHOT: Could not find artifact org.openhab.addons.bundles:org.openhab.addons.reactor.bundles:pom:2.5.1-SNAPSHOT 
and 'parent.relativePath' points at wrong local POM @ line 6, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:     
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

[remisharrock]

So should I clone https://github.com/openhab/openhab-core and/or https://github.com/openhab/openhab-addons and/or https://github.com/openhab/openhab-distro

It looks like openhab-addons already upgraded to 2.5.2-SNAPSHOT : openhab/openhab-addons@bd8f322#diff-727e725d63708f6c7b919fabbf33d792

Do you know how I can set-up a dev env. to compile your new binding and test it by deploying it on my openhabian "stable and in production" env ?

[fruggy83]

I am using VS Code as IDE. I justed cloned the official openhab-addons and added the openocean repo as a submodule at the right place. gitmodules file

[submodule "bundles/org.openhab.binding.openocean"]
	path = bundles/org.openhab.binding.openocean
	url = https://github.com/fruggy83/openocean.git

I will update the jar today.

[fruggy83]

Hi @remisharrock,

openHAB team updataed the current release to 2.5.2. I will try to update my source accordingly. Had not found time yesterday (unexpected root canal treatment).

[remisharrock]

@fruggy83 All right !
And I also use VS code as my main IDE, so I'll set everything up ! Thank you again and I also went to the dentist twice for my teeth :) good luck !

[remisharrock]

here is a little testing, it doesn't seem to work properly but I don't know why. I tried different things and report what's happening here :

I installed the avidsen device. It has a button and 3 leds: one blue, one green and one orange.

and the log is too long so I put all my tests here:

https://gist.github.com/remisharrock/5174c47ab09e1a1769f54f3a4602ff0d

[fruggy83]

Hi @remisharrock,

thanks a lot for your testing. I just forgot to implement the receiving part in my current implementation. So changes done directly on the device will have no effect in openhab. This is fixed now.
However I am currently not sure why the sending part is so unstable. Sometimes it works and sometimes not. In both cases the send message is identical. How far is your enocean gateway away from your advisen device? Maybe the messages really get lost?

Bellow you find a new version which has implemented the receiving part too. Would be nice if you could test this again.

org.openhab.binding.enocean-2.5.2-SNAPSHOT.jar.zip

[remisharrock]

thank you for looking through my looong log !
receiver and emitter are very very close together (one meter, I even tried 2cm :)
It looks like the receiving of the power measure is working now, as you can see in this log:
( the test device has the id : 0586A922 , other devices are also communicating)

https://gist.github.com/remisharrock/76547ed2aace6829c1d321f49a8e312c

But I still have the problem when I send a command, now it works less than 10% of the time.

What is surprising is that when I push the button and change the pilot wire mode manually on the device, the state change is always received correctly.

I did the last test with the antenna very close to the device (like 3, 4 cm): when I change the pilot mode in PaperUI, it fails 90% of the time (the device doesn't do anything)... very strange.

Also, in the version just before there was an option to repeat the sending message a certain number of times, It looks like I cannot configure this anymore.
I tried with the old version by putting something like "repeat the message 5 to 10 times" and it looks like the command was sent 5 to 10 times and the device changed its mode correctly around the 7/8 repeated command sent.... very strange ? I have other devices, maybe this one does not work correctly, I'll try a new one and let you know.

[remisharrock]

also in paperUI, even if in the log the power measure was sent, it is not reflected in the paperUI :

[remisharrock]

oups no, my bad, I had the same variable for everything;
now I'm trying to understand what the switch is doing ? I can see it sends ON and OFF commands but it doesn't seem to do anything...
and even sometimes the device sends itself that it is switching to OFF... by itself without doing anything ? I have to investigate further...

[fruggy83]

Hi @remisharrock,

your device supports EEP D2-01-0C which has a switching command support, but maybe it just ignores it and always sends back Off for the switch command. This switching command is cannot be compared to the pilot wire OFF command. So maybe you should just ignore it for your device.

receiver and emitter are very very close together (one meter, I even tried 2cm :)

Ok in this case receiption quality should not matter.

What is surprising is that when I push the button and change the pilot wire mode manually on the device, the state change is always received correctly.

Hm.. this seems to me that this device goes into something like a sleep mode where it does not receive any messages. After a short period of time it wakes up and receives new messages. As I do not understand french (learnd latin in school 🤦‍♂ ) , could you ask the advison support, if this is correct? The guys from NodOn (also a french company) were very helpful in implementing the other parts of the EEP D2-01 family.

If this device goes into a sleep mode, if have a solution for this "problem" too. Dominik and I already implemented a request/response communication mode, where we just send a message, after we received a message from a device.

Also, in the version just before there was an option to repeat the sending message a certain number of times, It looks like I cannot configure this anymore.

The repeating mode is still not available in the official binding as I want to refine it a little bit.

[remisharrock]

I have sent this message to avidsen, waiting for their response:
Bonjour, nous sommes en train d'implémenter avec deux développeurs qui ne parlent pas français le protocole D2-01-0C enocean pour le module chauffage fil pilote, il s'agit du binding openocean de openhab. Nous recevons bien les ordres de changement lors de l'appui sur le bouton depuis le module mais lorsque nous envoyons des ordres de changement, le module réagi uniquement une fois sur 10 environ...parfois moins. On se demande s'il faut implémenter une sorte de protocole request/response ? On se demande si le module entre dans une phase de "sleep" et qu'il faut d'abord le réveiller avant d'envoyer une commande ? Pouvez-vous nous aider pour finaliser l'implémentation ? Voici les détails techniques des tests et implémentations actuellees (en anglais) merci : #85

[remisharrock]

it looks like it's a hardware default, I have to send my devices back and they will send me new ones, known issue !

[fruggy83]

Hi @remisharrock, thanks for the update 👍 . Do you think I can push the changes to the official binding or should I wait until you receive your new devices?

[remisharrock]

as you wish, I sent the devices last week, I'll be back next monday, as soon as I receive the new device I test again right away and let you know !