Enocean/eltako FSB14 percentage unreliable

Add-ons Bindings
, ,
1

I have two issus with the enocean binding:

  1. When I do sendCommand(80) (jsscripting) a second time on the same rollershutter after it has reached the position from the first sendCommand(80), the rollershutter moves all the way down.

First sendCommand(80) (moves correctly to ~80 %):

11:53:56.543 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
11:53:56.553 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A5000A0208000000120001FFFFFFFFFF00
11:53:56.559 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Unknown/unsupported ESP2Packet: 6B07000A02080000001200
11:53:56.976 [DEBUG] [internal.messages.ESP2PacketConverter] - Received ESP2 message telegram: 8B05020000000000001230
11:53:56.978 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Converted to: RADIO_ERP1 with RORG RPS for 00000012
11:53:56.979 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 00000012 payload F6020000001230 received
11:53:56.981 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload F6020000001230 for 00000012 received

Reached position:

11:54:07.998 [DEBUG] [internal.messages.ESP2PacketConverter] - Received ESP2 message telegram: 8B070064020A0000001220
11:54:08.000 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Converted to: RADIO_ERP1 with RORG _4BS for 00000012
11:54:08.008 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for 00000012 payload A50064020A0000001220 received
11:54:08.010 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload A50064020A0000001220 for 00000012 received

Second sendCommand(80) (no movement):

11:54:41.053 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
11:54:41.055 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A500000208000000120001FFFFFFFFFF00

Third sendCommand(80) (moves completely down):

11:55:02.265 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
11:55:02.266 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A500000208000000120001FFFFFFFFFF00
11:55:02.284 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Unknown/unsupported ESP2Packet: 6B07000002080000001200
11:55:03.037 [DEBUG] [internal.messages.ESP2PacketConverter] - Received ESP2 message telegram: 8B05020000000000001230
11:55:03.040 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Converted to: RADIO_ERP1 with RORG RPS for 00000012
11:55:03.042 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 00000012 payload F6020000001230 received
11:55:03.043 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload F6020000001230 for 00000012 received

Reaches end:

11:55:33.324 [DEBUG] [internal.messages.ESP2PacketConverter] - Received ESP2 message telegram: 8B05500000000000001230
11:55:33.326 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Converted to: RADIO_ERP1 with RORG RPS for 00000012
11:55:33.328 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 00000012 payload F6500000001230 received
11:55:33.330 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload F6500000001230 for 00000012 received

Thing and item:

Bridge enocean:bridge:fam14 "Eltako Bridge FAM14" [
  path="/dev/ttyUSB0",
  rs485BaseId="00000000",
  rs485=true,
  enableSmack=true,
  espVersion="ESP2",
  sendTeachOuts=false
] {
  Thing enocean:rollershutter:actuator_office_west "Rollladenaktor Büro Westen" [
    enoceanId="00000012",
    senderIdOffset=18,
    sendingEEPId="A5_3F_7F_EltakoFSB",
    receivingEEPId="F6_00_00","A5_3F_7F_EltakoFSB"
  ] {
    Channels: Type rollershutter:rollershutter [shutTime=13]
  }
}

Rollershutter rollershutter_office_west "Rollladen Büro Westen" <rollershutter> (Office, rollershutter_west, rollershutter_west_og, rollershutter_og) ["Blinds"] {channel="enocean:rollershutter:actuator_office_west:rollershutter", autoupdate="false"}
  1. Some FSBs don’t react to the first command at all. They at least need a second or somtimes third command. I do have the same behaviour via the hardware switch though. Is there something like a deep sleep mode? This is the reason I’d have to send the same command multiple times, but it would lead to the problem I’ve described above on the shutters that moved correctly with the first command.

Any ideas?

2

Hi,
I use several FSB14 and I don’t need to send a command multiple times.
They react every time, no matter whether I send it via OpenHab or a physical switch.

If the problem also exist with the “non smart” physical switches, the problem must be your setup. Maybe you should check via PCT14 for some strange entries or behavior.

How many power supplies are build into your Eltako bus? It is possible that the voltage drops to too far, so the actor won’t work. Maybe the non responding FSB’s are at the end of the bus where to voltage is the lowest? (You can measure the voltage with a multimeter at the pins, or calculate the needed power with the data sheet at page 3 https://www.eltako.com/fileadmin/downloads/de/_bedienung/RS485-Bus-Reiheneinbaugeraete_Baureihe_14_Planungshilfe_und_Betriebsanleitung_dt.pdf )

I got 3 power supplies in my system.

3

Hi Dirk,

good to hear that it’s not a general eltako or openhab issue. I will check the PCT14. Anything special I should look for?

I have one FSNT and one SNT for 13 FSBs. Are these the power supplies?

Maybe the non responding FSB’s are at the end of the bus where to voltage is the lowest?

No it’s pretty random. The voltage should be enough according to my electrician.

Does sending the same percentage to the FBS multiple times work for you via openhab?

4

I never tried sending the same percentage several times, because it works everytime with the first command :slight_smile:

If the problem occurs with your hardware switches too, the problem must be within your bus setup.

If the bus is setup correctly (addresses etc.) the only thing I can imagine is the voltage.

Your electrician should check the voltage at the bus (the power supplies can be worn out over time) and fix the hardware switch issue first.
When this works correctly, you can try to set up openhab.

5

Interestingly the issue isn’t present, when I remove my OpenHAB system’s USB connection to the FAM14. Everything works as expected without it when using the hardware switches. As soon as I connect to the FAM and start to control shutters via OpenHAB, the hardware switches need a second push.

The voltage has been checked and everything is fine (it has been installed just some months ago).

Anything left that I could check?

6

No sorry, never experienced anything like that.
I don’t use the usb connection, I use a wireless connection via usb300 modul.
So all my button and commands are working properly.

7

Of you want a wired connection, i strongly recommend a fgw14-usb. You can add this to your existing setup. I got one and i am really pleased with it. It polls the staus of your actuators every x seconds.

8

Thanks for the suggestion. I haven’t chosen the FGW14, because it wasn’t recommended by my previous software (iobroker). As it should work with the FAM14, I’ll dig deeper into it before buying another gateway.