EnOcean 2: FGW14-USB supported

Hi Markus,
with position 2 the message looks the same as with Pos. 5 and the switch in Openhab does not change to a new status:

Hmm, I have my FAM14 set to position 2, but I am using an Enocean-Receiver not USB connecting to my Pi.
Based on the logs you posted the ACK-messages are not seen by OpenHAB, just the radio-messages from the switches.
Not sure how to debug from here, perhaps @fruggy83 can give a hint on what to try next.

Hi @damator Daniel,

If you connect your pi with the FAM14 you are directly connected with the RS485 Bus. The devices on the bus are not identified by their EnOceanId. They just use their Bus Id. So instead of the EnOceanId FFAEEC00 you have to use an Id like I guess 00000014.

Best regards
Daniel

HI @timtatam Timo,

how did you configured your FSB14 in openhab? As I stated before, you have to use the BusId instead of the EnOceanId for your devices if you directly connect to your FAM.

BusId = EnOceanId - BaseId of your FAM14 (calculated in hex values) as a FAM14 just supports 128 controllable devices on the bus you can just use the last byte of the Ids :slight_smile:

Best regards
Daniel

thanks fruggy for the hint.
In the thing configuration I changed the EnoceanID from FFAEEC00 to 0000014.


The ESP packet payload is now forwarded to the EnOceanBaseThingHandler but the switch is not updated. (tested in FAM mode 2 and 4).

After that is working I can also support in writing a short tutorial about the configuration with FAM14 and FSR14 by direct USB connection.

Great! This was the trick, now it works for me.

Athough I have now a follow up question: how do I get the angles of my blinds?

I configured the following:

Thing enocean:rollershutter:ogBedroomBlindsSlide "Blinds" (enocean:bridge:b1935554) [
    enoceanId="00000001",
    senderIdOffset=1, 
    sendingEEPId="A5_3F_7F_EltakoFSB", 
    receivingEEPId="A5_3F_7F_EltakoFSB","F6_00_00",
    broadcastMessages=true,
    suppressRepeating=false
    ] {
        Channels:
            Type rollershutter : rollershutter [shutTime=25]
            Type angle : angle []
    }

and

Rollershutter Shutter_OG_Bedroom_SlidingDoorWindow "Bedroom Sliding Door NEW [%d%%]" <blinds> (OG, gShutterBlinds, OG_Bedroom) { channel="enocean:rollershutter:ogBedroomBlindsSlide:rollershutter", autoupdate="false"}
Number Shutter_OG_Bedroom_SlidingDoorWindowAngle "Bedroom Sliding Door Angle [%d]" <blinds> (OG, gShutterBlinds, OG_Bedroom) { channel="enocean:rollershutter:ogBedroomBlindsSlide:angle", autoupdate="false"}

somehow it doesnt display anything in the GUI. Any ideas?

Hi @fruggy83 Daniel,

I have some difficulties connecting via de FGW-14. The base ID of my FAM14 is FFF87600, the dimmer I would like to connect with has address 2. I set the address of the gateway to 00000000 and the address of the FUD14 to 00000002. In the dimmer configured 00000002 as GFVS. When I connect via the USB of the FAM14 everything seems to work but when I use the FGW-14 the dimmer is not responding. When I use the wall switches the dimmer is updated in OH. I tried a lot of combination to get it working but Iā€™m completely stuckā€¦ can you (or someone else) give me some advise? Many thanks!!!

I havenā€™t tried the Enocean binding yet (ATM my very old OpenHAB installation is bridged to the FTS14 via a self-written MQTT bridge). But checking your configuration (I think) it is a bad idea to set ā€œDimmer configured 00000002 as GFVSā€ to the same address as your actor is (the address of your FUD14 is also 2).

Is it on purpose that you configured your FUD14 to listen to GFVS (function 32) with ID 1-4?

I could provide better help with the message logs to see what happens on the bus.

How do you get the BaseId of the FAM14/FGW14?

OK, over the weekend I played around with my setup and I think I figured out how the setup with a FAM14/FGW14 is working. It worked for me with a FUD14 - controlling and feedback.

First some clarification about the Enocean-Things configuration parameters:

  • Since you you use a FAM14/FGW14 all things configuration has to be done manually:
    • add an Enocean Gateway as thing and configure it to use ESP2, enable Gateway directly connected to RS485 and put your FAMs Encoean ID as Base ID (I"m not sure if setting the base ID to the FAM address is needed, see my notes below).
  • Enocean ID: the address your actor is using = the FTS14 bus id. Following your example it would be 00000002 for the FUD14.
  • Sender ID: the (virtual OpenHAB Gateway) ID controlling your actor. You have to pair your FUD14 with this address, otherwise you can not control the FUD from OpenHAB. I personally never use the FTS14/Enocean/OpenHAB teach-in functionally since I have to many motion sensors/people in my house which would screw the configuration. So I use PCT14 to configure the actors.

Following your example above:

  • FAM14: FFF87600
  • FUD14 bus address: 2 (dec) ā€”> Enocean ID: 00000002
  • Sender ID: 2 ā€”> you have to configure the function group 3 in your FUD to 0xFFF87602 (0xFFF87600+0x2) with ā€œdimming value of GFSā€

Note:

  • Donā€™t use the Dec setting in the PCT14 to configure the ID but the hex one (I was not able to get it work with the decimal setting)
  • I just followed your example. The sender address could be any ID between 1-127. You just have to make sure you book keep all used sender IDs.
  • Iā€™m not sure if you need to configure your FAM14 address as Base ID for the Enocean Gateway or if you could pick any address which would make sure you have no ID collisions between the IDs provided by the Enocean Gateway and the RS485 bus actor IDs. Maybe @fruggy83 can tell more. Since I do not use the radio functionality of my FAM14 I just picked a base address which higher than the actor IDs (which were all below 128).

Your explanation in the last post are good but I think this last note is wrong. One should not set the rs485baseID to the FAM14 address. In my case there were conflicts on the bus. It could happen that you send with the same ID that already exists from an enocean device connected to the bus. One should set any other Base ID than the FAM14 address.

Hi,

you need to set a fictive base ID between 0000A000 and 0000DFFF. That is the address range Eltako sees for servers like their GFVS.

Hi Michael,

your comment is remarkable. But I wonder that the adress in my case ā€œFFFAAC00ā€ is working with the FAM14 and the FSR14. Maybe the first 4 Bytes are ignored somehowā€¦

Technically, all address ranges are valid. However, there might be collisions.
For example, I started using 00000000. SenderID 2 became 00000101, SenderID 3 became 00000103 => irrational behaviour.

In your case, somewhere might be a wireless Enocean device having an address in this rangeā€¦

Dear community,
for some month I used a connection to FAM14. It worked but the reliability was bad. Sometimes the FAM14 forgot so send feedback messages e.g. if you send several messages in a row to switch off several lights in one room. Therfore it was difficult to use the binding in rules. Some days ago I added the FGW14 and this is great. The reliability is 100%. I would really recommend to use FGW14 instead of FAM14 if you need device feedback.

Hi at all,

I have a question regarding the sender ID of the FGW14-USB gateway, maybe anyone was still in touch with this. My understanding of the FGW14-USB is, that this gateway supports 127 unique sender IDs and for an actor like the FSR14-4x I would need 4 sender IDs (each output channel = one sender ID).

So therefore I have the chance to setup 127 different actors (Lights, Dimmers, Heating etc). Right now Iā€™m planning the electrical installation of my house (hopefully build up by the end of this year) and at the moment I have about 80 actors and therefore sender IDs. I know there are some IDs left until 127 but, how knows what will happenā€¦

So the question is, did anybody test a configuration with two FGW14-USB gateways to get more sender IDs? Or other gateways?

Best regards
Stefan

Hi @flysl88 ,
I am not sure about the Fwg14, but with the Fam14 you can also use idā€˜s above the 127. But for these idā€˜s there are no acknowledgement telegrams. But you can still use them for actors where you donā€™t need it.

If you need more than 127 idā€˜s with acknowledgement telegrams you need to build a second bus.

Best regards
Dirk

Hi @dirkdirk ,

thanks for the hint with the FAM14. I will try it. As I said in my post above, I donā€™t think that I will need more than 127 IDā€™s but it would be good to know if it would workā€¦

Best regards!
Stefan

Hi @mkrebs

could you please tell me where you have found this information?
Many thanks!

Regards

I guess thats wrong for the fgw14. As the device acts as a ā€œrealā€ gateway.
The fgw14 would pass any telegram form the bus to the connected device (openhab). Also it would send any telegram, regardless of the used ID, to the bus as it has no fixed internal ID range like other gateways (eg. USB 300 Stick).
Iā€™ve tested this with FHEM and it worked. Unfortunately itā€™s blocked in openhab to use IDā€™s >127 as the limitation from other gateway are also applied here but that could be ā€œfixedā€ by creating a special FGW gateway device without that limitation

regards