Sorry I don’t quite understand this, can a switch be an FSR14 (have one that switches a plug socket) or is it a switch on the wall to push?
It would be interesting to have this FSR14 not as a light entity.
But isn´t the wall-mounted switch a sensor?
wall-mounted switches are binary_sensors.
I’ve actually never really tested switch type. I put it on the list. For me it is actually not really clear because eep M5-38-08 is no official eep (not listed in the standard). It’s definitely a one byte message because it has org=5 which is actually a binary sensor telegram or it could be used as a status update telegram of an actuator.
I changed the “fallback value when no discriminator found” in switch.py from 0 to 2 for the “on” value and from 1 to 3 for the “off” value.
def turn_on(self, **kwargs: Any) -> None:
"""Turn on the switch."""
address, discriminator = self._sender_id
if self._sender_eep == F6_02_01:
if discriminator == "left":
action = 0
elif discriminator == "right":
action = 2
else:
action = 2 <============== changed 0 to 2 =========
And now the other relay switches. So if there is a way to get “left” and “right” in the id in the configuration.yaml I can have the two relay’s working from the one ID-address. And looking at the code from util.py there is a way to separate the ID address and the discriminator but don’t know how…
class AddressExpression(tuple):
"""An object around the 4-long byte strings passed around for addressing
purposes. This supports parsing and serialization for user-readable
purposes (esp. in home assistant), but also adds the possibility to add a
discriminator string (eg. "00-21-63-43 left", stored as (b'\0\x32\x63\x43',
'left')) to the address which is used in the programming area to express
sub-features of an address that neither fit there nor in the profile."""
def __repr__(self):
return "<%s %s>" % (type(self).__name__, self)
def __str__(self):
return b2a(self[0]).replace(' ', '-') + (" %s" % self[1] if self[1] is not None else "")
@classmethod
def parse(cls, s):
plain, delim, discriminator = s.partition(' ')
if not delim:
discriminator = None
plain = bytes(int(x, 16) for x in plain.split('-'))
if len(plain) != 4:
raise ValueError
return cls((plain, discriminator))
I not a coder and don’t understand what happens in this line
plain, delim, discriminator = s.partition(' ')
but it looks to me that if there is a ’ ’ after the ID the value of discriminator gets that value.
But both
- id: FF-8C-E8-82 left
and
- id: "FF-8C-E8-82 left"
don’t work. Any other options?
so it tested it. Therefore I needed to get rid of a little bug but now it works. From my perspective it only makes little sense if you enter the button itself as id. If I bush the button defined with left then the state is for a short moment displayed and jumps back when I release the switch.
I think it should rather be used like a light then only the symbol would be different.
From my perspective you should enter the switch in the actuator directly.
If you want to react on switch telegrams and if you want to know from which button it came, you can use binary_sensors and automations like described here.
I want anyway to extend this whole thing because I would like to be able to define hidden switch combinations across many physical switches. E.g. when you bush both top buttons of two switches you could use this as door opener for child safety lock or to unlock your automation screen. …
Hint: event_ids will change again with next release.
To your question what can be a switch: As far as I understood and tested every relay sending a org=5 status update. That would be FSR, FMZ, FSB, FUD, FHK, FAE …
Does this help? What do you actually want to do?
As mentioned before I use an FSR12 in my system. This is a device with 2 relay’s.
One relay is used for the garden lights the other for switching on the coffee machine.
The ID of the FSR12 is FF-8C-E8-82. So what I would like to happen that if I send an “on” to FF-8C-E8-82 left the garden light should switch on but if I send it to FF-8C-E8-82 right the coffee machine should switch on.
So the config should look something like this:
switch
- id: FF-8C-E8-82 left <======= does not work
eep: M5-38-08
name: "Garden_light"
sender:
id: FF-8C-E8-82 left <======= does not work
eep: F6-02-01
- id: FF-8C-E8-82 right <======= does not work
eep: M5-38-08
name: "Coffee_machine"
sender:
id: FF-8C-E8-82 right <======= does not work
eep: F6-02-01
But this does not work.
And to be very clear my switch is an actuator and not a button or sensor that will be pressed.
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.