Eltako FAE14SSR / FHK14 / F4HK14 and Enocean Binding

Hi,

after having connected FSR14 with Openhab by using the FAM14 USB interface in the next step I would like to control the FAE14SSR from Openhab. In the headline I also added FHK14 and F4HK14 as these use the same protocol but in the following I’ll only use the term FAE14SSR.

In the Eltako Enocean documentation I was able to find the following protocol documentation for the FAE14SSR (confirmation message):
grafik

In the PCT14 Software the FAE14SSR can be configured with following relevant options:
Funktionsgruppe 1:
grafik
Funktionsgruppe 3:
grafik

In a standard setup without openhab the FAE14SSR is linked to e.g. a FTR55DSB (roompanel). These sensors use the follwing protocol:
grafik
Thus in PCT14 for the FTR55DSB the “64” A5-10-06 is selected.

I already know that the FAE14SSR needs to get temperature setpoint and Actual temperature inputs to be able to control the room temperature.
My Target is to control the FAE14SSR by Openhab rules so that for example all heatings can be switched off/on independently from the roompanel setpoints. Therefore I would like to influence the FAE14SSR behaviour by sending setpoints to these actors from Openhab rules, e.g. setpoint 40°C ==> heating always on, setpoint 8°C heating always off. The direct setpoint channel from the roompanel to the FAE14SSR must therefore be interupted. The setpoint must be send by using a appropiate EEP. A temperature signal must be sent cyclic, either simulated or forwarded from a roompanel.

It tried the following:
FAE14SSR Thing:

Thing centralCommand ht_OG_H_3_1 "H-OG-Bad-HK" @ "OG Bad" [enoceanId="00000029", senderIdOffset=29, sendingEEPId="A5_10_06", receivingEEPId="F6_00_00", broadcastMessages=true, suppressRepeating=false ] //ID29 FFEAAC29

SetPoint ITEM
Number H_OG_Bad_TempSet_OPENHAB "Setpoint Bad OPENHAB" {channel="enocean:centralCommand:gtwy:ht_OG_H_3_1:setPoint"}

Temperature ITEM (Roompanel) - Roompanel is forwarding the temperature to openhab and fully functional

Number:Temperature H_OG_Bad_Temp "Temperatur Bad" {channel="enocean:roomOperatingPanel:gtwy:pn_H_OG_Bad:temperature",
                                                       channel="enocean:centralCommand:gtwy:ht_OG_H_2_2:temperature",
                                                      channel="enocean:centralCommand:gtwy:ht_OG_H_3_1:temperature"}

Problem is: In the debug window I cannot see that any data is being sent (no sending requests) to the FAE14SSR although it works for other configurations like FSR14-4x…
Any idea how to come a step ahead?

This reminds me of the classical XY Problem … (you ask for help with your solution instead describing what you want to achieve).

The main issue is that neither of your devices is supported directly by the binding nor does Enocean allow to “interrupt” a signal.

If all you want is “switch on/off” the heating via rule then use the capability that the actor provides: teaching in a 4-button switch for these functions:
grafik

Then create a “classic device” in the binding, register it to the actor via PCT14 and use GUI or rules to send the button-presses.
This will give you at least “off and normal” (and “saving”) via rules (normal operations controlled by the roompanel).

Hi Markus,

thanks for that hint, maybe it solves the problem. I have the following use case:
A bathroom heater is connected to the low temperature floor heating system, addtionally I have installed a electric heating device inside the bathroom heater that allows high temperatures.
The idea is that this electric insert will boost the bathroom heater temperature if someone requests it. The request to boost the bathroom temperature for e.g. 30min will come from an FTR55DSB that is already installed in the bathroom. I want to detect the request as a change in setpoint temperature of FTR55DSB. I already found out that this works fine by using a rule. After the request is detected the floor heating system shall be switched off and the electric insert is switched on for 30min so that the heater can reach a higher temperature. After 30min the electric device is switched off and some minutes later the floor heating system is switched on again so that then the heater is supplied from the heating system at least with low temperature.

Your solution would work only if the setpoint is set to a high temperature so that the heating is always switched on. But at least then because I will not use the FTR55SB to control the bathroom temperature - it is not needed as the low temperature floor heating in the bathroom is set to always on and even then the temperature will not overshoot 22°C…

Hi,

today I tried the following:
I left all the Funktionsgruppen empty. In Funktionsgruppe 4 there is the Option to set the FAE14SSR to the mode 29: 4-Fach-Testtaster. I added first the ID of a FT55 normal rockerswitch to the Testtaster and it worked, the FAE14SSR reacts in the right way. Following meassages I find in the debug:
(FROM PHYISCAL WALL ROCKER SWITCH ORIGNAL MESSAGE: ==> Switch to ON confirmed)
0B 05 10 000000 FEF42EA3 30 “PRESSED”
0B 05 00 000000 FEF42EA3 20 “RELEASED”

(FROM PHYISCAL WALL ROCKER SWITCH ORIGNAL MESSAGE: ==> Switch to OFF confirmed)
0B 05 30 000000 FEF42EA3 30 “PRESSED”
0B 05 20 000000 FEF42EA3 20 “RELEASED”

Then I tried to see if I can do the same from OPENHAB. Therefore I added the adress FFFAAC29 to the Funktionsgruppe 4 in the same way like in the Rockerswitch. But with my configuration from OPENHAB I was not able to send the same meassages, and it doesn’t work yet.

I created a classicDevice :

Thing classicDevice

ht_OG_H_3_1 “H-OG-Bad–K” @ “OG Bad” [senderIdOffset=41, sendingEEPId=“F6_02_01”, receivingEEPId=“F6_00_00”, broadcastMessages=true, suppressRepeating=false ]
{
Type virtualSwitchA : virtualSwitchLO [duration=300, switchMode=“toggleButtonDir2”]
Type virtualSwitchA : virtualSwitchLU [duration=300, switchMode=“toggleButtonDir1”]
}

And linked the channel to items as follows:

Switch H_OG_Bad_HK_Switch_OFF “Switch Off” (Heizung_PrioA){channel=“enocean:classicDevice:gtwy:ht_OG_H_3_1:virtualSwitchLU”}
Switch H_OG_Bad_HK_Switch_ON “Switch On” (Heizung_PrioA){channel=“enocean:classicDevice:gtwy:ht_OG_H_3_1:virtualSwitchLO”}

The debug output is:
6B 05 30 000000 FFFAAC29 30
6B 05 00 000000 FFFAAC29 20
or
6B 05 10 000000 FFFAAC29 30
6B 05 00 000000 FFFAAC29 20

After each packet there comes “Unknown/unsupported ESP2Packet:”…

Any hint how to send exactly the same like the pyhsical rocker switch? My bridge is working in the right way as I’am already able to control the FSR14-4x.

Hi Daniel @damator,

your settup looks good to me and the messages are genereated as expected.
6B => TX, 05 => RPS Telegram, 30/10 Press or 00 Release, 000000 unused data, FF… senderId (baseId + 0x29 = 41 decimal), 30/20 CC.
So could you please post the part after “Unknown/unsupported ESP2Packet:”. I would like to know which data you receive here. By the way I am currently advancing the PTM EEP to control a FHK14 and receive its current state.

Best regards
Daniel

Hi Daniel @fruggy83,

an EEP control for FHK14 would be great. To keep all similar to FSR14x4 control it could make sense to use the Setpoint from GVFS in Funktionsgruppe 3. If you need some support for testing then I can help out.
Below you find the LOG and TRACE for Switch OFF control (lower button of the left side):
2021-01-10 12:50:58.785 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘H_OG_Bad_HK_Switch_OFF’ received command OFF

2021-01-10 12:50:58.827 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'H_OG_Bad_HK_Switch_OFF' predicted to become OFF

==> /var/log/openhab/openhab.log <==

2021-01-10 12:50:58.837 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback

2021-01-10 12:50:58.846 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F630FFFAAC293001FFFFFFFFFF00

2021-01-10 12:50:58.859 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Unknown/unsupported ESP2Packet: 6B0530000000FFFAAC2930

2021-01-10 12:50:59.172 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback

2021-01-10 12:50:59.174 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600FFFAAC292001FFFFFFFFFF00

And the TRACE:
==> /var/log/openhab/events.log <==

2021-01-10 12:56:03.957 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'H_OG_Bad_HK_Switch_OFF' received command OFF

2021-01-10 12:56:03.963 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'H_OG_Bad_HK_Switch_OFF' predicted to become OFF

==> /var/log/openhab/openhab.log <==

2021-01-10 12:56:03.972 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:03.973 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:03.976 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:03.980 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback

2021-01-10 12:56:03.984 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F630FFFAAC293001FFFFFFFFFF00

2021-01-10 12:56:03.987 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: A55A6B0530000000FFFAAC29309E

2021-01-10 12:56:04.004 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.005 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.007 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 3

2021-01-10 12:56:04.009 [TRACE] [nternal.messages.ESP2PacketConverter] - Received Transmit_Radio_Telegram: 6B0530000000FFFAAC2930

2021-01-10 12:56:04.012 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Unknown/unsupported ESP2Packet: 6B0530000000FFFAAC2930

2021-01-10 12:56:04.020 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.021 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.023 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.083 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.098 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.100 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.131 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.132 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.134 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.179 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.180 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.182 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.227 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.228 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.230 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.275 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.276 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.278 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.291 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback

2021-01-10 12:56:04.294 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600FFFAAC292001FFFFFFFFFF00

2021-01-10 12:56:04.296 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: A55A6B0500000000FFFAAC29205E

2021-01-10 12:56:04.307 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.308 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.310 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 3

2021-01-10 12:56:04.311 [TRACE] [nternal.messages.ESP2PacketConverter] - Received Transmit_Radio_Telegram: 6B0500000000FFFAAC2920

2021-01-10 12:56:04.313 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Unknown/unsupported ESP2Packet: 6B0500000000FFFAAC2920

2021-01-10 12:56:04.339 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.340 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.341 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.387 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.388 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.390 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.435 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.436 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.437 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.483 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.484 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.485 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.531 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.532 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.533 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.579 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.580 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.582 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.643 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.644 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.645 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.691 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.692 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.696 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.739 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.740 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.741 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.787 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.789 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.791 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.835 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.837 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.839 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.883 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.909 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.911 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.947 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.949 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.951 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:04.995 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:04.997 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:04.998 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.043 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.045 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.046 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.091 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.093 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.095 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.140 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.141 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.143 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.203 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.205 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.207 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.251 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.253 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.255 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.299 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.301 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.303 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.347 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.349 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.351 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.395 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.397 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.399 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.443 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.445 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.447 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.507 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.509 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.511 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.555 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.557 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.559 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.603 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.605 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.607 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.651 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.653 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.655 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.699 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.701 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

2021-01-10 12:56:05.703 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 11 packet type 5

2021-01-10 12:56:05.747 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received First Sync Byte

2021-01-10 12:56:05.772 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Second Sync Byte

Hi Daniel @damator

To keep all similar to FSR14x4 control it could make sense to use the Setpoint from GVFS in Funktionsgruppe 3.

My plan was to implement some new messages for the PTM EEP to mimic a simple rocker switch (finished this already). In this case you could control the operation mode (normal, night, reduced and off) and receive the current state of an FHK14. If you want to set the setpoint too, we have to find the right EEP first. I could not find any hints about the EEP but would guess to use the A5-38-08 subcommand 0x04 basic setpoint. However I am not sure how the FHK will react to the different setpoints set by openhab through this EEP and the setpoint coming from your room panel. The documentation is not clear at this point if openhab would overwrite the roompanel in this case :man_shrugging: So testing would be really neccessary. Which openhab version do you use?

I will fix the problem with the unknown ESP2Packet in the next release. I thought that the gateway would never receive a Transmit_Radio_Telegram. I expected that it would be changed to a Receive_Radio_Telegram.

Best regards
Daniel

Hi @fruggy83 ,
I think the correct way to set the setpoint for the FHK14 is to do it with the room control panel.
openhab ->room panel ->FHK14.

E.g the Futh65d do it that way with Gfvs:

Steuerung mit der GFVS-Software
Mit der GFVS-Software wird dem FUTH65D eine Solltemperatur vorgegeben. Solltemperatur ohne Priorität bedeutet, dass die Solltemperaturen der einzelnen Räume individuell angepasst werden und zwar nur wenn sie außerhalb von ±3°C liegen. Beispiel: Die Solltemperatur wird von der GFVS mit 20°C vorgegeben. Raum 1 hat die Solltemperatur 22°C und bleibt unverändert. Raum 2 hat die Soll- temperatur 16°C, es erfolgt eine Korrektur auf 17°C. Raum 3 hat die Solltemperatur 25°C, hier erfolgt eine Korrektur auf 23°C. Bei einer Solltemperatur mit Priorität werden die Solltemperaturen aller Räume auf die Solltemperatur der GFVS gesetzt.
Die Steuerung durch die GFVS wird durch ein Telegramm mit der Solltemperatur 0°C beendet. Wird länger als 1 Stunde kein Telegramm von der GFVS empfangen, wird die Steuerung ebenfalls beendet. Wird der FUTH65D von der GFVS angesteuert, erscheint ein Funksymbol im Display.
Der Schiebeschalter wird von der GFVS überstimmt, FTK haben jedoch Priorität.

There is the “Priorität” which is important for setpoint. Afaik a attribute must be set as “block” or “unblock” to achieve the “Priorität” setpoint. (At least in Fhem)
I think the EEP for controlling the FHK is the A5-10-06.

I also use 2x F4HK14, so if you need support with testing let me know.
I am on openhab3.0.0 stable.

Best regards Dirk

Hi Daniel @fruggy83,
that you are working on this topic is really good to hear. I want to do energy & comfort optimization of the whole heating system (heat pump, phovoltaik and wood oven) and therefore these unusual control path is essential :face_with_raised_eyebrow:. Currently I would only need the operation mode - exactly what you already plan to implement. But if the setpoint is also available it would lead to more flexibility for the user.
Then following path could be implemented:
Room control panel -> openhab (pass through of the value or rule based change) -> FAM14 or other Bridge-> FHK14.
@dirkdirk: The path openhab -> room control panel is in my opinion more exotic and propably then also redundant (e.g. FTR55DSB can not be influenced from GVFS…).
I’am also using OH3.0.

@damator
For me personal your shown path wouldn’t be useable.
If openhab doesn’t work for any reason you are not able to pass through the setpoint to the fhk14. So there is no temperature adjustment anymore for the rooms.
I configured my whole Eltako setup for an independent use so that I am able to control everything without the need of openhab or gfvs. I got for everything physical devices.
I use openhab „only“ to automate everything, logging and for central and remote controlling, so that I am don’t have to live in the dark or cold when openhab stops working :rofl:

This is why I prefer to use the other way…
If you control your room operating panel from openhab, the last transmitted value to the panel will be used, no matter whether OH is working or not.
This is a lot safer I think, at least for me.

Hopefully there will be both options, if you own a room operating panel which is able to receive commands from openhab, you can use it this way, otherwise you use it the way you suggested.

But I am confident @fruggy83 will bring a nice solutions as always.

Best regards Dirk

hi, could you share the version where you mimic the simple rocker switch? I would like to start with that.

Hi at all,

does anyone found out the correct setting for the roomOperatingPanel Thing to control the setpoint of the room panel? I have a test bench setup with one F4HK14 and one BUTH55D control panel. Those work good together, I’m already able to get the temperature and setpoint into OH3. Now i would like to set the setpoint from OH3 to the control panel.

// Thing
Thing roomOperatingPanel BUTH55 "Thermostat" @ "Office" [enoceanId="00001909", sendingEEPId="A5_10_06", receivingEEPId="A5_10_06" ]

// Item
Number EG_Office_Setpoint "Solltemperatur [%.1f °C]" <temperature> (gEG_Buero) ["Setpoint","Temperature"] {channel="enocean:roomOperatingPanel:gtwy:BUTH55:setPoint", listWidget="oh-stepper-item"}

This is working from outside world into OH3, but not vise versa… Does anyone have an idea?

Best regards
Stefan

Hi @flysl88 ,
I am also still looking for a way to set the setpoint at my room panels.
Afaik the room coontrol panels are not useable as an actor at the moment. They are only sensors for the binding. See here:

I know that @fruggy83 was working at the PTM200 telegrams for the F4HK14 (to read their state) and also at the room control panels.
See here:

I installed the latest openocean binding v 3.1 but I still can’t get them to work and unfortunately I didn’t read anything from him in the last few weeks. Hopefully he is doing well.

Hi @dirkdirk ,

thank you for this information! So in this case we are still looking forward to a way to set the setpoint in a proper way. However, I will try to use different EEPs, maybe I have luck…

Best regards!
Stefan

Hi Guys,

so is it possible to set the setpoint for F4HK14 directly? What I saw from the post is that we can’t overwrite the setpoint of the roomOperatingPanel (which I have sr07p in the house)

Hi,
I don’t know any solution to set the setpoint or read the current state of the F4HK14. Also the room control panel is not supported to receive commands.
Maybe there will be something new when @fruggy83 releases a new version.

Hi Hamid @templeofair

as @dirkdirk said, the roomOperatingPanel SR07P cannot receive any messages, so we cannot overwrite its setpoint. This is only possible with a more advanced RoomOperationPanel like SR06. These panels are bidirectional and can receive a setpoint and other parameters.

However I am working on different improvements for the RoomOperatingPanels: support some new panels like RBW from Kieback, improve support for SR06 and adding a virtual thermostat to control FHK14, F4HK14. This virtual thermostat uses simple EEP A5-10-03 to send current temperature value and a setpoint. Furthermore it is possible to read and set the different modes for these FHK like auto, standby night (Nachtabsenkung), standby and off. However you have to be aware that these FHK expect a message from your (virtual) panels each hour. If they do not receive a message within a hour they activate a fault mode (Störbetrieb). So be sure that your openhab instance is running :slight_smile:

Best regards
Daniel

Hi Daniel @fruggy83 ,
I am really happy to hear you are working on the room operating panels :heart_eyes:

Will it be possible to use the Futh65 the same way like it is working with Gfvs described here?

Or do I need to send the setpoint temperature directly to the F4HK14?

Let me know when I can support you with a test of the room panel, F4HK14 or any other enocean device I own.

Best regards
Dirk

Hi Daniel @fruggy83

Thanks for the info. I think the virtual thermostat would be great however that constant communication is a tricky part(maybe we can echo the temperature which we get from the roomOperatingPanel back to FHK every hour) Looking forward to use the new feature :slight_smile:

Best regards,
Hamid

Hi @fruggy83

just wanted to check for the status of the improvement for the RoomOperatingPanels. I’m working with the BUTH55 RoomPanels and F4HK14 actors. Is there already a way to set the setpoint of the BUTH55 from OpenHab3?

Best regards!
Stefan