New openHab2 EnOcean binding

Thank you very much for the new EnOcean Binding :+1:

I use an Eltako Rocker Switch FT55 to switch between 4 light scenes of my light panel (Hue:0210 
) in my kitchen. Most of it works fine except a minor thing. When I release the rocker switch button the color temperature always changed from 100 to 87 even it should stay 100, as you can see from the log

2019-03-18 12:48:32.132 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA triggered DIR2_PRESSED

2019-03-18 12:48:32.143 [ome.event.ItemCommandEvent] - Item ‘Taster_Kueche_links’ received command OFF

2019-03-18 12:48:32.147 [nt.ItemStatePredictedEvent] - Taster_Kueche_links predicted to become OFF

2019-03-18 12:48:32.152 [vent.ItemStateChangedEvent] - Taster_Kueche_links changed from ON to OFF

2019-03-18 12:48:32.154 [ome.event.ItemCommandEvent] - Item ‘Licht_EG_Panel_Kueche_KW’ received command 100

2019-03-18 12:48:32.159 [ome.event.ItemCommandEvent] - Item ‘Licht_EG_Panel_Kueche’ received command 100

2019-03-18 12:48:32.166 [nt.ItemStatePredictedEvent] - Licht_EG_Panel_Kueche_KW predicted to become 100

2019-03-18 12:48:32.175 [nt.ItemStatePredictedEvent] - Licht_EG_Panel_Kueche predicted to become 100

2019-03-18 12:48:32.182 [vent.ItemStateChangedEvent] - Licht_EG_Panel_Kueche_KW changed from 87 to 100

2019-03-18 12:48:32.185 [vent.ItemStateChangedEvent] - Licht_EG_Panel_Kueche changed from 0 to 100

2019-03-18 12:48:32.383 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA triggered DIR2_RELEASED

2019-03-18 12:48:33.374 [vent.ItemStateChangedEvent] - Licht_EG_Panel_Kueche_KW changed from 100 to 87

I use the following item definition

Switch Taster_Kueche_links “Taster KĂŒche links” { channel=“enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA” }
Switch Taster_Kueche_rechts “Taster KĂŒche rechts” { channel=“enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchB” }

and the following rules

// KĂŒchenlicht aus -AUS
rule “KuechenTaster links oben”
when Channel “enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA” triggered “DIR1_PRESSED”
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(0)
end

// KĂŒchenlicht hell warmweiß - Romantik
rule “KuechenTaster links unten”
when Channel “enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchA” triggered “DIR2_PRESSED”
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(100)
end

// KĂŒchenlicht warmweiß gedimmt - Nachtlicht
rule “KuechenTaster rechts oben”
when Channel “enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchB” triggered “DIR1_PRESSED”
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(30)
end

// KĂŒchenlicht hell kaltweiß - Arbeiten
rule “KuechenTaster rechts unten”
when Channel “enocean:rockerSwitch:A60149OK:FEF8B1BF:rockerswitchB” triggered “DIR2_PRESSED”
then
Licht_EG_Panel_Kueche_KW.sendCommand(0)
Licht_EG_Panel_Kueche.sendCommand(100)
end

Any idea how to solve this issue? I’m not sure if the issue is EnOcean or Hue related.


 If I use the OH App on my tablet I can change the color temperature to 100 and it stays 100

Hi Bernhard @BG56

really strange behaviour :thinking:. I do not think that this is related to the EnOcean binding. Could you try to create the rockerswitchA Pressed rule with a dummy switch item? I am not sure, if you can switch this dummy item in PaperUI, as it just shows linked channels. So you have to put this dummy item in a sitemap and switch it through BasicUI.

Are you sure that you have not defined a rule for the RELEASED event? The temperature change occures approx one second after RELEASED is triggered. Could you please try to activate the debug log, maybe we can see who is responsible for the color change in this way.

Best regards
Daniel

Hi Tanel @Ratiomatic,

first of all, if an actuator send its state back as a response to a switch command, I would always recommand to deactivate the autoupdate feature on the item. In this way the internal state of an item is not changed when you switch it manually in the gui. It has to be changed explicit by the binding, for example after receiving the response.

For a similiar case I am working on a retry policy. I send the command again and again until I receive a response (see here). You can use the retryInterval and retryTries properties to configure the policy. This feature should already be integrated in the current release.

Just to make sure, the NodOn switch just sometimes does not react on the switch command? Or does it never react on the OFF command?

Best regards
Daniel

By the way: Thanks a lot for the :coffee: :+1:

Hi Daniel @fruggy83,
Again thanks for all of your efforts, the binding is taking a really usable form. Some more common EEPs to implement and soon the OpenHAB is the best choice when it comes to Enocean support. It is really easy now to make your existing home pretty smart without any new cabling.

I was on snapshot build when testing the issue. It happened on both transitions ON->OFF and OFF->ON

After installing the latest beta, I disabled the autoupdate on the relay things and entered the retryInterval and it works like a charm, I can now go crazy on the window-contact and it checks out everytime.
By default the retryInterval was 0 (did not retry) does this mean no retry is set or is it done with suppressRepeating?
Can you please exlain further what the sendBroadcast option would do? I can’t imagine use of broadcast with the relay module.

Hi Daniel,

thank you for your quick reply. I have no rules for the RELEASED events defined.

I’m back home on Friday and will test what you have proposed. I just want to clarify that I understood what you mean. I should define


 a dummy item:

Switch Dummy_Item “Dymmy Item”


 and put the dummy item into the sitemap:

Switch item=Dummy_Item


 and change one of the rules to test:

when Dummy_Item triggered “ON”
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(0)
end

Are item, sitemap and rule as you proposed for testing?

Regards,

Bernhard

HI Bernhard @BG56,

withe the exception of the rule, the proposed steps are fine. I would just replace the rule, which sets both items Licht_EG_Panel_Kueche_KW and Licht_EG_Panel_Kueche to 100, as this rule gets triggered when you press your Taster_Kueche_links.
So take the following one

when Dummy_Item triggered “ON”
then
Licht_EG_Panel_Kueche_KW.sendCommand(100)
Licht_EG_Panel_Kueche.sendCommand(100)
end

In this case you can simulate your button press without using the EnOcean binding. If it still the same behaviour, we know that it cannot be related to the EnOcean binding.

Best regards
Daniel

Hi Tanel,

the retryInterval defines after how many milliseconds without a response from the device the message is send again. The retryTries defines how many times the message is repeated (I know, the naming of these options is not the best). If one of these options is set to 0, the retry policy is deactivated.
The option suppressRepeating controls if a message is allowed to be repeated by an EnOcean repeater. @ThAO had a use case for this.
Some devices just react on messages which are directly addressed for them. Other devices just react on broadcast messages. In most cases I can detect this correct. In all other cases you have to set this option accordingly. All VLD (D2) messages must be directly addressed, so broadcast for a relay should always be deactivated. Maybe I should define this option as an advanced option and hide it for a better usability.

Best regards
Daniel

Hello Daniel @fruggy83

I have played around again the last days

But unfortunately I was struggling with some “beginner” problems.

Im still not able so see the telegram content.
log:set TRACE org.openhab.binding.openocean has no effect in my logging output.

But I can confirm when I setup 0x000001xx addresses in my actuators I am able to control my lights over FGW14. If this was different over FAM14 in your tests I wish to be able to change the Base ID.
Otherwise users has to use different actuator settings depending on their connection because FGW seems to change sender ID.

But at the moment a face a different problem:
Most of the time i get the message: No SerialPortProvider found for: /dev/ttyAMA0

When this happens, I am still able to send over this interface but I can not receive anything.
Can somebody guide me what serial feature:install I have to do on the latest snapshot.
I have added the users to dialout already over openhabian-config and I tried it manually also.

Thanks for your help!

Best Regards,
Rainer

Hi @fruggy83 @dominikkv
Please will somebody involved post a short instruction and maybe update the documentation how to utilize the Generic Thing using A5_FF_FF or D2_FF_FF. I have looked trough forums and can’t get an idea how this can be done to receive numeric values, all examples are with MAP transform.

For example if I wanted to read EEP A5-09-04 how to get the raw data and divide it to 3 raw bytes (Temp, Humidity and CO2 value in this case) Should we use this with JS transform?
I think this would solve many seldom used EEPs, that neccessarily do not need full support.

Hi Rainer @jahnra,

you can enable the debug log with log:set debug org.openhab.binding.enocean
I kept the binding id of the official version, so you do not have to change your config files when you switch between the official version and openocean.

I should be sufficient to just feature:install openhab-transport-serial in the karaf console.

Could you please tell me more about your setup? Is it like RaspPi => FGW14 => BUS => FAM14 => WinEtel? Is WinEtel connected by USB or by radio with FAM14? I just checked again but I cannot image why 256 should be added to the senderId.

Best regards
Daniel

Hi Tanel @Ratiomatic,

for complex and not yet implemented EEP like D2 EEP we must use a Generic Thing in conjunction with a JS transform. A simple MAP transform would be to complicated as you have to list all different combinations in you mapping file. I have not found time yet to document a JS transformation. So if you have time, it would be great if you could create an example.

Best regards
Daniel

Hello Daniel @fruggy83,

log:set debug org.openhab.binding.enocean
instead of
log:set debug org.openhab.binding.openocean
was successful - thank you!

Yes, it is exactly like this. and FAM14 was connected over USB to WinEtel.
Sending over ttyAMA0 => FGW14 is looking like:

2019-03-26 00:00:49.167 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback

2019-03-26 00:00:49.171 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600000000012001FFFFFFFFFF00

But the actuator programmed to address 0x00000101 will respond. With ttyUSB0 over FAM14 this actuator does not respond.

The FGW14 is designed also to connect two series 14 buses. I guess this behaviour is normal to not have a conflict between the actuator status messages of two different buses. I’m sure that FGW14 will modify the sender address when a address between 0 and 255 is received. Because of this, modifying the BaseId in this mode would be great


With my serial problem I did:

sudo service openhab2 stop
sudo openhab-cli clean-cache
sudo service openhab2 start
feature:install openhab-transport-serial on Karaf

After I was able to receive over ttyAMA0, but after openhab2 restart or reboot the raspi, receiving channel is dead again! :thinking:

Update:
I used a fresh installation with only openocean.
This seems to solve my problem also: New openHab2 EnOcean binding - #449 by fnu

Best Regards,
Rainer

First I need a hint how to access the raw payload, when I just assign a variable to Number there is no update. I also tried the JS transform to just return the value:
(function(inputData) {
return (inputData);
})(input)
Only thing I can get is last update timedate:
11:12:01.985 [TRACE] [ternal.transceiver.EnOceanTransceiver] - Received Sync Byte
11:12:02.002 [TRACE] [ternal.transceiver.EnOceanTransceiver] - >> Received header, data length 12 optional length 7 packet type 1
11:12:02.013 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 050466FE payload D24000E00000B0050466FE0000FFFFFFFF2E00 received
11:12:02.022 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload D24000E00000B0050466FE00 for 050466FE received
11:12:02.138 [INFO ] [smarthome.event.ItemStateChangedEvent] - VM_Pressac_VU changed from 2019-03-26T11:11:31.880+0200 to 2019-03-26T11:12:02.118+0200

Hi @Ratiomatic, @JGKK, and all other asking for more info on genericThings

following you find a generic implementation of EEP D2-03-0A. This EEP is used by NodOn SoftButtons. I hope that this example is helpful and can be adopted to any other not yet implemented EEP.

Thing definition

Thing genericThing NodOnButton "Button" [ 
      enoceanId="AABBCCDD",
      sendingEEPId="D2_FF_FF", 
      broadcastMessages=true, 
      receivingEEPId="D2_FF_FF",
      suppressRepeating=false] {
      
        Channels: 
            Type genericNumber : genericNumber [transformationType="JS", transformationFunction="generic.js"]
            Type genericString : genericString [transformationType="JS", transformationFunction="generic.js"]
            Type genericSwitch : genericSwitch [transformationType="JS", transformationFunction="generic.js"]
      }      

generic.js file

(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 "genericSwitch":
            if(b[1] == 1){
                return "OnOffType" + "|" + "ON";
            } else if(b[1] == 2){
                return "OnOffType" + "|" + "OFF";
            }
            break;
            
        case "genericRollershutter":
            break;
            
        case "genericDimmer":
            break;
        
        case "genericNumber":            
            return "DecimalType" + "|" + b[0];
            
        case "genericColor":
            break;
            
        case "genericString":
            if(b[1] == 1){
                return "StringType" + "|" + "SinglePress";
            } else if(b[1] == 2){
                return "StringType" + "|" + "DoublePress";
            } else if(b[1] == 3){
                return "StringType" + "|" + "LongPress";
            } else if(b[1] == 4){
                return "StringType" + "|" + "LongRelease";
            }
            break;
            
        case "genericTeachInCMD":
            break;
    }
    
    return (inputData);
})(input)

The transformation function is provided with a string consisting of “ChannelId” + Pipe + “Payload”. The generic.js file already contains a helper function which converts the payload into a byte array (b). The result of the transformation function has to be “OpenHAB State” + Pipe + “Value”. Just return inputData, if you cannot convert it.

Best regards
Daniel

ps @JGKK I have already implemented the EEP, however as long as it is not published you can use this generic thing approach. The number channel holds the battery status in percent.

2 Likes

Hi @fruggy83,

Thanks for the clear example. Works fine.
Slight problem is only having one number value as genericNumber
A5-09-04 has 3 Number values, I managed to extract CO2 to genericNumber and humidity + temperature into one genericString.
Is it the best way to solve it right now? Later dividing the string into two numbers using a rule.

Hi,

does anybody has a NODON temperature & humidity sensor? It is written on the back that it uses EEP A5-04-01. However the teach-in data (received by FHEM) looks like this:

2019.03.09 17:06:02 4 : EnOcean Unknown device with SenderID 051173E2 and STE telegram, activate learning mode.
2019.03.09 17:06:02 5 : EUL dispatch EnOcean:1:31:0324AC221D9CBE457A:051173E2:00:01FFFFFFFF4900
2019.03.09 17:06:02 4 : EnOcean received via EUL: EnOcean:1:31:0324AC221D9CBE457A:051173E2:00:01FFFFFFFF4900
2019.03.09 17:06:02 5 : EnOcean received PacketType: 1 RORG: 31 DATA: 0324AC221D9CBE457A SenderID: 051173E2 STATUS: 00
2019.03.09 17:06:02 4 : EnOcean Unknown device with SenderID 051173E2 and ENC telegram, activate learning mode.

I would not expect RORG 31 here. Does anybody has an idea?

Thorsten

I have one of the Nodon temperature and humidity sensors, don’t know about the teach in message but the teach in and function works without any problems in the openhab enocean binding.


 just saw on GitHub that the NODON temperature & humidity sensor is supported. I guess I don’t get it running because I use 2.5.0.SNAPSHOT.

Im using it with the openocean 2.5.0.1 binding

Hi Johannes @JGKK,

did you use the configuration files to set it up. This is my preferred way to do it. If yes, you might give me a hint how to do it.

Thorsten