sorry that was not clear for me that FSR12 has only one address then it definitely makes sense.
Oke, do you have an idea how this should be configurated in the config file?
This is the same thing as a FSR14 with 1, 2 or 4 relay’s.
Hello @heubie,
I’ve checked how to program and use FSR12 and how FHEM uses FSR14.
Few facts:
- FSR12 is not sending status update telegrams => switch needs to keep shadow state
- Actually you need to listen to switch telegrams as well so that you have awareness of state changes.
- FSR12 every channel works independently
- FSR12 has no address to which commands can be sent (no push instead pull)
- Buttons need to be teached-in. Same for Home Assistant, virtual buttons need to be teached-in like in FEHM.
Conclusion:
From my perspective we could
- reuse all the platform tyes in HA (switches, light, cover, heating, …)
- their ids would have no meaning to series 12 (because no commands and status updates are supported.)
- there must be a flag so that state is kept persistently.
- state changes when trigger in HA is pushed or telegrams from switches are received.
- existing sender in config can be used like today to be teached-in into FSR12 in addition to the existing physical switches like it is in FHEM.
What do you think about it?
What you could try out as preparation is to just create an arbitrary entry and test if you can teach-in the virtual switch into FSR12. e.g.:
switch:
- id: 00-00-00-01 # this id does not matter, just take something free to receive no status updates from other devices
eep: M5-38-08
name: FSR12 - 1
sender:
id: "00-00-B0-01 left" # This is the button you need to teach-in. Follow the constructions to teach switches in and instead of pushing a physical switch press the button in HA.
eep: F6-02-01
I’ve released the new gateway id schema and within it I fixed the switch bug. Sorry for the breaking changes again. Hopefully next time you can keep the config structure.
Did some testing and after installing 1.2.2 this is what is happing:
if this is my config:
eltako:
gateway:
- id: 1
base_id: FF-8C-E8-80
device: fgw14usb
devices:
switch:
- id: 00-00-00-82
eep: M5-38-08
name: "Gardenlight"
sender:
id: FF-8C-E8-82 left
eep: F6-02-01
I get this error when I want to restart HA
Invalid config for [eltako]: [device] is an invalid option for [eltako]. Check: eltako->eltako->gateway->0->device. (See /config/configuration.yaml, line 177).
But when I remove the “device: fgw14usb” like so:
eltako:
gateway:
- id: 1
base_id: FF-8C-E8-80
# device: fgw14usb
devices:
switch:
- id: 00-00-00-82
eep: M5-38-08
name: "Gardenlight"
sender:
id: FF-8C-E8-82 left
eep: F6-02-01
The restart works and when I toggle the device in HA the logging says:
2023-12-18 08:58:46.963 DEBUG (SyncWorker_12) [eltako] [Gateway] [Id: 1] Send message: <RPSMessage from ff 8c e8 82, db0 = 10, status = 0x30 (T2, N, 0 repetitions)> - Serialized: a55a6b0510000000ff8ce88230a5
2023-12-18 08:58:46.963 DEBUG (SyncWorker_12) [eltako] [Gateway] [Id: 1] Send message: <RPSMessage from ff 8c e8 82, db0 = 00, status = 0x30 (T2, N, 0 repetitions)> - Serialized: a55a6b0500000000ff8ce8823095
2023-12-18 08:58:49.204 DEBUG (SyncWorker_6) [eltako] [Gateway] [Id: 1] Send message: <RPSMessage from ff 8c e8 82, db0 = 30, status = 0x30 (T2, N, 0 repetitions)> - Serialized: a55a6b0530000000ff8ce88230c5
2023-12-18 08:58:49.205 DEBUG (SyncWorker_6) [eltako] [Gateway] [Id: 1] Send message: <RPSMessage from ff 8c e8 82, db0 = 20, status = 0x30 (T2, N, 0 repetitions)> - Serialized: a55a6b0520000000ff8ce88230b5
But there is no information on the RS485 bus???
So the question is: does it need the device-type “fgw14usb” to send data to the RS485 bus?
And if so, why does it give this error when I put it in the config file?
Hello @heubie,
thanks for pointing it out and big sorry, I forgot to update the docs for this. Now you can find it on main branch.
Instead of device you need to use device_type. Wanted to have this more clear. It is requested so that I can derive the right parameters for the specific gateway. FAM-USB has e.g. a different baud rate.
Small tip: Recently, I’ve added the file example configuration file to a unit test which means when ever something is not correct tests will not pass.
In general I’ve added a lot more tests to avoid incompatibilities when I do changes. Unfortunately, it is not easy to simulate HA and the devices, so testing is quite limited but definitely helps. I try to improve the whole thing. Unfortunately, my night hours, to work on that thing, are quite limited and lack of concentration is also often present. 
@philipp14 No need to say sorry. I’m very glad you put in al the hard work.
It works now!!!
Since I know al the ID’s of all my devices I don’t have to teach anything to use it in HA.
The fact that BR12 doesn’t send update telegrams is no big issue.
There are some direct links between buttons and actuators (like wall switch and lights) and there are software links where the button is pressed and the actuator is switched via an automation for example.
So like you mentioned I “double the direct link” with a software one in HA. Therefor the status of the actuator is always updated.
So next step is to fade out FHEM and then start using the FAM-usb as gateway. This is now in use to keep FHEM running.
Hello @heubie,
I’ve extended the switch entity in a way so that it could work for series 12.
I actually only added support for F6_02_01 for the switch which means it listens to switch commands instead of actuator status updates.
eltako:
general_settings:
fast_status_change: True # must be set to True so that it keeps the state and is not waiting for status updates of the actuator
show_dev_id_in_dev_name: True
gateway:
- id: 0
device_type: fgw14usb
base_id: FF-AA-80-00
devices:
switch:
- id: FE-DB-B6-40 left # when switch is pushed it changes the state because actuator of series 12 is not sending updates. You can specify nothing (all buttons), left or right. see also in the code above.
eep: F6-02-01 # eep of switch
name: My switch
sender:
id: 00-00-B1-32 # if you want to change the state from HA use this address. I was able to teach-in this command by using the rotary switches on the actuator. I did that for FSR14 because I do not have series 12.
eep: F6-02-01
Hopefully that works for you.
The switch already worked for me, so I don’t know why it needed updating. Could you explain it?
How do you receive the status update of the actuators when you use a wall-mounted switch?
And when I tested the button push was switching it on and when I released the button it turned off.
Do you actually have wired or wireless switches?
How do you receive the status update of the actuators when you use a wall-mounted switch?
I make an automation which does the same as wall mounted switch (so the actuator gets switched on twice) and therefor HA will also be updated
And when I tested the button push was switching it on and when I released the button it turned off.
I use the entities of the devices with on and off
Do you actually have wired or wireless switches?
I use wireless switches.
1 Like
Just a small question, if I can control the device with the fgw14 and I replace the gateway with my fam-usb and update de configuration.yaml accordingly everthing should work again, right?
Hey @heubie,
unfortunately, this will be not enough. I’ve extended the example here to show it:
(In the gateway docs it is describe in more detail. The differences are better to see in the little example. )
First there is a fgw14 with one light if you would like to change that like below you need to take both of the base_ids from fam14 and fam-usb and add those to the addresses.
What you can do for testing is: you can configure the same light e.g. 00-00-00-01 two times in both gateways and it will also work in parallel and synchronize. I use that for testing as well.
It works because then the actuator sends the status update telegram after the change then it sends with address 00-00-00-02 on the internal bus and that fgw14 receives. Then fam14 sends it into wireless network with its base id FF-AA-00-02 and then fam-usb receives it. This is why it automatically updates both entities in HA.
I want to switch from one gateway to another for testing.
So from
eltako:
gateway:
- id: 1
base_id: FF-8C-E8-80
device_type: fgw14usb <=========== working system
#device_type: fam-usb
#device_type: fam14
devices:
switch:
to
eltako:
gateway:
- id: 1
base_id: FF-8C-E8-80
#device_type: fgw14usb
device_type: fam-usb <============= testing
#device_type: fam14
devices:
switch:
After this delete Eltako intergration.
And reinstall so the new gateway becomes active.
Yes, it should.
I haven’t found it in the forum nor the documentation. What position does the BA switch on the FAM14 needs to be?
For everybody who wants to do some testing or monitoring and don’t want to spend a whole lot of money. If you by a simple and cheap USB<->RS485 device connect the A and B connections to the BR14 bus you can monitor the data via a PC. (56000 baud)
I tested also that if you put the FGW14 as your gateway it works as well.
Btw. the BR12 RSA-RSB bus is also a RS485 but at 9600 baud.
sorry for the quality…
1 Like
I connected the FAM14 to my HA and installed the Integration as described in the documentation.
Unfortunately the initial setup won’t work, I get following error:
So I added the gateway to the configuration:
But still the same error.
It starts first with eltako:
See example config here:
It does. The Eltako: is in the configuration.yaml and the rest in the included eltako.yaml
Have the same for modbus and mqtt integration. This way the configuration.yaml stays clean and I have all devices from one integration in an seperate yaml.