New openHab2 EnOcean binding

openhab2-addons
enocean
binding
Tags: #<Tag:0x00007f0142f41790> #<Tag:0x00007f0142f41600> #<Tag:0x00007f0142f414c0>

(Helge Rege GΓ₯rdsvoll) #522

I’m trying to control/dim a FUD61NPN from OpenHab.

I attempted to activate teach in on the acutator (central on/off) with the signals sent from openhab, but no response.


(Martin) #523

Did you define the enocean ID right? aabbcc01 seems to be the value from the binding documentation.

Furthermore I checked the documentation of the actuator. Maybe you set the mode of the actuator to Auto to teach in your dim channel.

Last hint, but not sure is to use Type dimmer for the channel definition in combination with a listener to validate that everything is setup correct. That worked for me.

Cheers and good luck


(Dominik Krickl-Vorreiter) #524

Hi Helge @helge,

I have set up my FUD61NPN just the other week, so I can give you some tips. As I think you have mastered the communication device -> OpenHAB, I only talk about OpenHAB -> device. My configuration looks as this:

Thing centralCommand 05014FC5 "Deckenlicht" @ "Schlafzimmer" [ enoceanId="05014FC5", senderIdOffset=14, sendingEEPId="A5_38_08_02", receivingEEPId="A5_38_08_02" ] {
    Channels:
        Type teachInCMD : teachInCMD [ teachInMSG="E0400D80" ]
        Type dimmer : dimmer [ rampingTime=0 ]
}
Thing genericThing 05014FC52 "Lichtwecker" @ "Schlafzimmer" [ enoceanId="05014FC5", senderIdOffset=14, sendingEEPId="F6_FF_FF", receivingEEPId="D2_FF_FF" ] {
    Channels:
        Type genericSwitch : genericSwitch [transformationType="MAP", transformationFunction="lichtwecker.map"]
}

Dimmer c_schlafzimmer_deckenlicht_dimmer "Dimmer [%d%%]" <light> {channel="enocean:centralCommand:usb300:05014FC5:dimmer"}
Switch c_schlafzimmer_deckenlicht_schalter "Schalter [%s]" <light> {channel="enocean:centralCommand:usb300:05014FC5:dimmer"}
Switch c_schlafzimmer_deckenlicht_lichtwecker "Lichtwecker [%s]" <bed> {channel="enocean:genericThing:usb300:05014FC52:genericSwitch"}

// Switch c_fud61npn_teachin "TeachIn" {channel="enocean:centralCommand:usb300:05014FC5:teachInCMD"}

// lichtwecker.map
genericSwitch|ON=70
genericSwitch|OFF=50
genericSwitch|70=OnOffType|ON
genericSwitch|50=OnOffType|OFF
  • You can control two things on the device: set a brighness, and activate the alarm clock. That’s the reason I have two Things.
  • Teach in: choose a senderIdOffset which is not used before. The EnoceanId OpenHAB uses to send the telegram is calculated with the BaseId + senderIdOffset. On the device, go to TeachIn mode (AUTO + LRN) and switch c_fud61npn_teachin from off to on. The blinking red LED should turn off. Leave an go again into TeachIn mode (AUTO + LRN) and switch c_schlafzimmer_deckenlicht_lichtwecker from off to on. Again, the LED should confirm the teach in. Now you can comment out the TeachIn Item and use the other Items.
  • With rampingTime you can control how fast the transition to the desired brightness goes, 0 = as set on the device. You have to use the latest Binding version from fruggy83/openocean to use this.
  • I have set receivingEEPId of the alarm clock Thing to a D2 EEP to never interpret data. The normal switching of the device is confirmed with a A5 AND F6 message, so this would also switch the alarm clock Item.
  • The two Things can have the same enoceanId and senderIdOffset as their telegrams have different RORGs.

Good luck :slight_smile:
Dominik


(niri) #525

Good morning @all,

we are about to renovate a house (inside-out). Is there anyone using raffstores with blind and angle control? I am still searching actuators that accurately transmit the blind position and allow me to set the blind angle.

Eltako Tippfunk does not correctly send the driving-time/give feedback about the position, furthermore I can’t find an implementation for blind angle control.

With the Nodon actuator I do see the blind position correctly, but no blind angle control.

Any recomendations?


(Dominik Krickl-Vorreiter) #526

I am happy with the Permundo PSC152, but I am not using the angle control. You can set the position as percent. It reports position, angle and power measurement every second when driving. Self-calibrating.

Edit: I see that the implementation of A5-38-08 CMD 7 (Blinds) lacks support for setting the angle, so if you need it I suggest to open an issue at fruggy83/openocean. Getting the angle from the device should work.


(Thorsten Oest) #527

Hi Daniel (@fruggy83),

since I had problems to move from openocean to the official enocean binding on my raspberry pi, I tried to test the fix on windows. Unfortunatelly I did not get the openocean binding running on windows so far. So I have to postpone the testing to the next weekend.

Best regards,
Thorsten


(Helge Rege GΓ₯rdsvoll) #528

thanks, this did the trick :slight_smile:


(Thorsten Oest) #529

Hi Frank (@fnu)

did you solve the problem with the unresolved requirements? I get exactly the same errors when installing the 2.5.0-SNAPSHOT on windows.

Best regards,
Thorsten


(niri) #530

Is there a new version available? I can’t find any retailer selling the PSC152.


(Frank) #531

Hi Thorsten (@ThAO),

which one?

In the meantime I’m able to make all my actuators run, the Nodon, the Peha and the Eltako ones. The Nodon get working thru discovery from PaperUI, my (older) Peha EBI ones (FW: <3.xx) need to be teached in with a teach in telegram, very similar to the Eltako TF ones:

Thanks for Daniels and Dominiks great work.

Cheers
Frank


(Thorsten Oest) #532

Hi Frank (@fnu),

I got these error messages which you also saw in your installation

 Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
 Unresolved requirement: Import-Package: org.eclipse.smarthome.config.discovery.usbserial

How did you resolve this?

Best regards,
Thorsten


(Frank) #533

I wrote it here: New openHab2 EnOcean binding

Bottomline I needed to install an other binding in prior, in my case yamahareceiver, what obviuously resolved the dependency issues …

Cheers
Frank


(Jens Bruckmann) #534

Hi Daniel (@fruggy83)

I just updated my installation to 2.5.0-SNAPSHOT Build 1500 with your binding updated from openocean to enocean.

After that I had a β€œnew” bridge with a new Base ID. So I teached in again my contact sensor.

2019-01-14 15:02:38.576 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Starting EnOcean discovery and accepting teach in requests
2019-01-14 15:02:46.411 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Received teach in message from 050F4EB0
2019-01-14 15:02:46.413 [INFO ] [covery.EnOceanDeviceDiscoveryService] - EnOcean Package discovered, RORG _1BS, payload D500050F4EB00
0, additional 01FFFFFFFF4900
2019-01-14 15:02:46.419 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'enocean:contact:FT1SETFA:050F4EB0' to inbox

The status of the item gets updated right after discovery:

2019-01-14 15:05:25.997 [vent.ItemStateChangedEvent] - EnoceanDoorContact changed from OPEN to CLOSED
2019-01-14 15:05:29.017 [vent.ItemStateChangedEvent] - EnoceanDoorContact changed from CLOSED to OPEN
2019-01-14 15:05:31.332 [vent.ItemStateChangedEvent] - EnoceanDoorContact changed from OPEN to CLOSED

The contact then works until I restart OH2.

After that the binding still seems to receive messages from the sensor but the item will not update.

2019-01-14 15:32:47.676 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _1BS for 050F4EB0 payload D508050F4EB00001FFFFFFFF4300 received
2019-01-14 15:32:47.679 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D508050F4EB000 for 050F4EB0 received
2019-01-14 15:33:04.185 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _1BS for 050F4EB0 payload D509050F4EB00001FFFFFFFF4700 received
2019-01-14 15:33:04.188 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D509050F4EB000 for 050F4EB0 received
2019-01-14 15:33:18.186 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _1BS for 050F4EB0 payload D508050F4EB00001FFFFFFFF4400 received
2019-01-14 15:33:18.189 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D508050F4EB000 for 050F4EB0 received
2019-01-14 15:33:21.012 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - 
RADIO_ERP1 with RORG _1BS for 050F4EB0 payload D509050F4EB00001FFFFFFFF4400 received
2019-01-14 15:33:21.014 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D509050F4EB000 for 050F4EB0 received

When I then delete the thing and teach it in again item updates work until next restart of OH2 again.

Another question is why the bridge seems to have another BaseID now. Because of that I will also have to teach in my Eltako switch again, too?!

Cheers,
Jens


(Tino) #535

Daniel (@fruggy83), many thanks for your explanation!!! Makes totally sense, to make it 100% bullet proof isn’t possible.

I will use a manual workaround, that I switch all my lights off before I start openHab and set the status to OFF when it start openHab.

I am currently using the toggle mode on the listener. Will re-define it and use the SwitchMode.

When I want to create a listener on the FT55, I guess I have to create the thing manually, because I saw no possibility within the PaperUI like when I devine a classic device.

Many Thanks for all your support!!!
Tino


(Daniel Weber) #536

Hi Jens @bruxi

there is currently a bug in the implementation of the Contact EEP D5. I have just approved the PR of @dominikkv. However the merge is still pending. If you want, you could use the snapshot from my repo, which has this fix already merged.

Best regards
Daniel


(Daniel Weber) #537

Hi Tino @flynux,

When I want to create a listener on the FT55, I guess I have to create the thing manually, because I saw no possibility within the PaperUI like when I devine a classic device.

In this case you just have to use the RockerSwitch thing, which just listens to a RockerSwitches like FT55 and emits events. You could also use profiles to link these listeners to other items. However be careful, these profiles use sendCommandto update the item. Therefore the items handle this updates as if you would manually update the item => the item sends a message. That is not a big problem in case you have a SwitchMode actuator (it is just sending an unneccessary message). However when you use a ToogleMode actuator, your lights will go crazy. Press FT55 => light goes on => listener receives message => sendCommand to item => thing sends message to light => light goes off. As you can see the RockerSwitches are mainly intended to control other thinks (like a Sonos, KNX rollershutters and so on) with your EnOcean FT55 rockers. However you can always create a rule which listens to the RockerSwitch events and use a postUpdate in it.

Best regards
Daniel


(Daniel Weber) #538

Hi Dominik (@dominikkv),

I think we should set up a Wiki page which contains the thing and item config of common EnOcean devices.

Best regards
Daniel


(Zeraphim) #539

Hi,

I am trying to setup a RFC2217 connection to a USB300. But it is not working properly.
In the logs I see:

2019-01-15 11:16:11.496 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: rfc2217://10.42.21.1:5000
2019-01-15 11:16:11.498 [DEBUG] [org.openhab.binding.openocean       ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=432, service.bundleid=191, service.scope=singleton} - org.openhab.binding.openocean
2019-01-15 11:16:11.498 [DEBUG] [org.openhab.binding.openocean       ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=431, service.bundleid=191, service.scope=singleton} - org.openhab.binding.openocean
2019-01-15 11:16:11.499 [DEBUG] [org.openhab.binding.openocean       ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=433, service.bundleid=191, service.scope=singleton} - org.openhab.binding.openocean
2019-01-15 11:17:11.510 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2019-01-15 11:17:11.554 [INFO ] [transceiver.EnOceanSerialTransceiver] - EnOceanSerialTransceiver initialized
2019-01-15 11:19:11.574 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2019-01-15 11:19:11.577 [INFO ] [transceiver.EnOceanSerialTransceiver] - EnOceanSerialTransceiver initialized
2019-01-15 11:20:11.580 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2019-01-15 11:20:11.585 [INFO ] [transceiver.EnOceanSerialTransceiver] - EnOceanSerialTransceiver initialized
2019-01-15 11:31:11.666 [hingStatusInfoChangedEvent] - 'enocean:bridge:gtwy' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2019-01-15 11:31:11.668 [hingStatusInfoChangedEvent] - 'enocean:bridge:gtwy' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_PENDING): starting rx thread...
2019-01-15 11:31:11.675 [hingStatusInfoChangedEvent] - 'enocean:bridge:gtwy' changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...
2019-01-15 11:31:11.676 [hingStatusInfoChangedEvent] - 'enocean:bridge:gtwy' changed from OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id... to OFFLINE (CONFIGURATION_ERROR): Port could not be found

Sometimes it begins working after some time without any additional notice in the logs. But most of the time it isn’t. I have to restart OpenHab several times until it is working. Not really relyable like that.

bundle:list | grep OpenOcean                                                                                                                                                                   
191 β”‚ Active   β”‚  80 β”‚ 2.5.0.201901112122     β”‚ OpenOcean Binding
feature:list | grep serial
esh.tp-serial-javacomm                      β”‚ 0.10.0.oh240     β”‚          β”‚ Uninstalled β”‚ distro-2.4.0            β”‚
esh.tp-serial-rxtx                          β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-config-serial                           β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-config-discovery-usbserial              β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-io-transport-serial                     β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-io-transport-serial-javacomm            β”‚ 0.10.0.oh240     β”‚          β”‚ Uninstalled β”‚ distro-2.4.0            β”‚
esh-io-transport-serial-rxtx                β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-io-transport-serial-rfc2217             β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
openhab-transport-serial                    β”‚ 2.4.0            β”‚ x        β”‚ Started     β”‚ distro-2.4.0            β”‚ Serial Transport
esh-binding-serialbutton                    β”‚ 0.10.0.oh240     β”‚          β”‚ Uninstalled β”‚ openhab-addons-2.4.0    β”‚
openhab-binding-serialbutton                β”‚ 2.4.0            β”‚          β”‚ Uninstalled β”‚ openhab-addons-2.4.0    β”‚ Serial Button Binding
openhab-binding-lgtvserial                  β”‚ 2.4.0            β”‚          β”‚ Uninstalled β”‚ openhab-addons-2.4.0    β”‚ LG TV Serial Binding
openhab-binding-serial1                     β”‚ 1.13.0           β”‚          β”‚ Uninstalled β”‚ openhab-addons-2.4.0    β”‚ Serial Binding

Can someone explain what is happening? I tried already clearing the cache and reinstalling the plugin.

Hope someone has an idea. Thanks

Edit:
I am using ser2net 3.5 on OpenWRT 18.06.1:

5000:telnet:0:/dev/ttyUSB0:57600 8DATABITS NONE 1STOPBIT remctl

The config for the bridge is:

Bridge enocean:bridge:gtwy "EnOcean TCP Gateway" [ path="rfc2217://10.42.21.1:5000" ] {
}

(Daniel Weber) #540

Hi @Zeraphim,

I think the first line in your log is reason for your problems.

No SerialPortProvider found for: rfc2217://10.42.21.1:5000

I am using the ESH serial API for the connection. Depending on the given path, it detects which SerialPortProvider should be used. If you path contains rfc2217 it just handles the connection over to the RFC-Provider. This provider is implemented in the feature esh-io-transport-serial-rfc2217. However this seems to be already running on your maschine. As I currently have no access to a karaf console, could you please tell me what this xmeans in the line openhab-transport-serial?

Best regards
Daniel


(Zeraphim) #541

Hi @fruggy83,

first thank you for your fast answer and for your effort of writing the plugin.

That could be why it is sometimes working. Depending which component claims acces to the transport.

The x is in the column required:

Name                                        β”‚ Version          β”‚ Required β”‚ State       β”‚ Repository              β”‚ Description
────────────────────────────────────────────┼──────────────────┼──────────┼─────────────┼─────────────────────────┼───────────────────────────────────────────────────
esh-io-transport-serial                     β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-io-transport-serial-javacomm            β”‚ 0.10.0.oh240     β”‚          β”‚ Uninstalled β”‚ distro-2.4.0            β”‚
esh-io-transport-serial-rxtx                β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
esh-io-transport-serial-rfc2217             β”‚ 0.10.0.oh240     β”‚          β”‚ Started     β”‚ distro-2.4.0            β”‚
openhab-transport-serial                    β”‚ 2.4.0            β”‚ x        β”‚ Started     β”‚ distro-2.4.0            β”‚ Serial Transport