Common mistakes — EnOcean SFSP receptor

General gateway problems (LED codes, box invisible on the bus, firmware update) are in Common mistakes. This chapter is what goes wrong with the EnOcean side specifically.

I paired a switch and nothing happens

Likely cause	How to tell	Fix
The box was not restarted	NbEmulatedInter on device/22/<n>/life is lower than the number of slots you filled	the pairing list is built at startup only — always write with --reboot
The identifier was mistyped	the state topic still reports that switch as unknown when you press it	re-read it and write it again
The slot number is not the instance you are watching	slot SfspInter5 publishes on device/23/5/life, not on device/23/0/life	watch the right instance
The switch is out of range from where it is fitted	it worked on the bench, not on the bulkhead	see What you need, and use rssi to find a better position

Pressing a switch reports nothing on the state topic

That topic only reports transmitters the gateway does not know. Silence means it is already paired — which is what you want, except when you are trying to read its identifier again. Turn on the report-everything mode for that:

muxen-uds -i can0 -F 22 -I <n> routine --action 1 --routine 2 --payload 01

It turns itself off at the next restart.

If the switch is not paired and the topic is still silent, the gateway is not hearing it at all. In order: check the switch works at all by pressing it standing next to the gateway; check the gateway is publishing its own life frame; check the switch model is one this firmware decodes — see What you need.

The same switch is in two slots

Only the lowest-numbered slot works. The gateway stops at the first slot matching the identifier, so the second one publishes a switch that exists on the bus but whose buttons never move. Clear the duplicate:

muxen-uds -i can0 -F 22 -I <n> writeconfig --name SfspInter<dup> --clear --reboot

A switch stays stuck "pressed"

The gateway holds a button down until the release telegram arrives, and releases it by itself after 5 seconds without any further telegram from that switch. A button that stays on longer than that means telegrams keep arriving — a jammed wall switch, or something on the boat sitting on it.

A button that is released too early, while somebody is still holding it, is the opposite problem: the switch is at the edge of its range and the repeat telegrams are not all getting through.

Two buttons pressed at once do not both report

The gateway reports the most recent event, not a running list of what is held. Pressing two buttons of the same switch together is understood as a combination and reported as such. Pressing two buttons in sequence and holding both is not: only the second one shows.

Only four buttons per transmitter are reported, bp0 … bp3. The bp4 … bp7 fields exist in the frame and are never set.

The gateway publishes nothing at all

Check its instance. A gateway on instance 63 is unconfigured and deliberately silent — it is the parking address, not a usable instance. Give it an instance between 0 and 62, see Commissioning.

An identifier appears that I did not press

Anything within radio range is reported, including a switch somebody else is pressing at the other end of the boat, and a switch in an installation next to yours. That is why the pairing procedure says to press twice and pair only the identifier that repeats.

It is harmless in service: an unpaired transmitter is only ever reported on the state topic, never published as a switch.

An EnOcean sensor never appears

Expected. Only switch telegrams are decoded; temperature probes, contacts and any other EnOcean sensor are received and discarded. There is no parameter that changes this.

A switch works intermittently

Watch rssi on device/23/<slot>/life while somebody presses it. It is the radio module's reading for the last telegram received from that switch, so it tells you what the gateway actually hears from that position — not what it hears from the bench.

Record the reading from a switch you know works reliably and use it as your reference, then move something: the switch, or the gateway. Metal between the two is the usual cause, and a repeat telegram lost in it is exactly what produces "works most of the time".

After a factory reset, every pairing is gone

Expected, and not recoverable from the equipment: the pairing lives only in the gateway — the switches themselves hold nothing. muxen-uds factory --reset-device-configuration clears all 63 slots and keeps the instance number. Restore from the CSV you saved at commissioning, or walk the boat pressing every switch again.

muxen-uds -i can0 -F 22 -I <n> readconfig --save-as-csv enocean-pairing.csv

muxen-uds locate does not blink the box

On this firmware the routine that normally blinks the LED is used for the report-every-transmitter mode instead, so locate lands on that mode and nothing blinks. Identify the box by its UID rather than by locate, and set the mode explicitly with the routine command shown above.