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.
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.
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
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
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.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.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.enoceanId
and senderIdOffset
as their telegrams have different RORGs.Good luck
Dominik
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?
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.
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
thanks, this did the trick
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
Is there a new version available? I canβt find any retailer selling the PSC152.
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
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
I wrote it here: New openHab2 EnOcean binding - #449 by fnu
Bottomline I needed to install an other binding in prior, in my case yamahareceiver, what obviuously resolved the dependency issues β¦
Cheers
Frank
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
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
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
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 sendCommand
to 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
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
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" ] {
}
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 x
means in the line openhab-transport-serial
?
Best regards
Daniel
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